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

Prepare the Mid-tier on OCI

Provision and prepare the mid-tier hosts for disaster recovery on Oracle Cloud Infrastructure (OCI).

Provision the Compute Instances for the Mid-tier Nodes

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

To take advantage of Oracle Customer Hub (UCM) licensing for Oracle WebLogic Server for Oracle Cloud Infrastructure, Oracle recommends using WebLogic for OCI images to provision the compute instances. You can provision Oracle WebLogic Server for OCI images using the Compute Instance Console or the Marketplace. These images are available for Oracle Linux 7.9 and 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
hydrwls1 HyDRCompmt AD1 Oracle WebLogic Suite UCM Image (Oracle Linux 7.9) VM.Standard2.2 hydrvcn midTierSubnet
hydrwls2 HyDRCompmt AD1 Oracle WebLogic Suite UCM Image (Oracle Linux 7.9) VM.Standard2.2 hydrvcn midTierSubnet

To provision the compute instances using the Compute Instance section in the OCI Console:

  1. Connect to the OCI Console for your tenancy.
  2. Select the proper region.
  3. Open the navigation menu and click Compute. Under Compute, click Instances, then click Create Instance.
  4. Provide the name 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, then perform the following steps:
    1. From the Image source drop-down, select Oracle Images. Select the Oracle WebLogic Server Enterprise Edition UCM Image or the Oracle WebLogic Suite UCM Image.
      You must select the same Edition that you are using in your on-premises instance.

      Note:

      Use of Oracle WebLogic Server GridLink data sources is an entitlement available only as part of the Oracle WebLogic Suite license.

    2. For the selected image, click the arrow on the right, and then select the image build version for the paid images, either Oracle Linux 7.9 (labeled release-ol7.9-build-timestamp) or Oracle Linux 8.5 (labeled release-ol8.5-build-timestamp.
      You must select the OS most similar to the one you are using in your on-premises instance.
    3. Review the terms and conditions and select the Oracle Terms of Use check box, then 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 Shapes for the images to find the supported shapes.
  8. Select the VCN, 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, then upload your public key, or paste the keys.
  11. Under Boot Volume, specify the size and encryption options for the instance's boot volume.
    To configure advanced settings, click Show advanced options.
  12. Click Create.
  13. Repeat the steps to create another compute instance.

Note:

You can find Terraform code to create these compute instances in Download Code.

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 secondary mid-tier hosts must meet the operating system requirements to run the software.

The binaries of the Oracle WebLogic Server homes will be copied from the primary WebLogic Server hosts to the secondary WebLogic Server hosts. Therefore, it isn't necessary to run the runinstaller in the secondary WebLogic Server hosts. The Oracle WebLogic Server for OCI images are prepared for the WebLogic Server software, hence, no additional packages are required to be manually added.

However, if you are using any Oracle Fusion Middleware product on top of WebLogic Server, make sure that the secondary WebLogic Server hosts meet the requirements:

  1. Ensure that your environment meets the minimum installation requirements for the products that are installed in primary WebLogic Server hosts.
  2. Verify the required system packages for your version and OS.
  3. Install the missing system packages with yum.
    This example uses Oracle Fusion Middleware 12.21.4 and Oracle Linux 7 and most 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 you on-premises WebLogic Server hosts and set the values in the OCI WebLogic Server compute instances accordingly.

Prepare Host Name Aliases

Configure the same virtual host names that are used by Oracle WebLogic Server components in the primary environment as aliases in the secondary Oracle Cloud Infrastructure (OCI) WebLogic Server compute instances, but point to the IP addresses of the secondary hosts.
You can implement this in the following ways:
  • Add the host names as aliases to the /etc/hosts files of the OCI WebLogic Server compute instances.
  • Use a private DNS view in the secondary OCI VCN.

Use /etc/hosts Files

The virtual host names used by the primary Oracle WebLogic Server are added to the /etc/hosts files of the secondary Oracle WebLogic Server hosts, pointing to the IP addresses of the secondary Oracle WebLogic Server hosts. This mode is valid when the DNS server is the same in 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.
  1. Edit the /etc/oci-hostname.conf file of each WebLogic 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 WebLogic Server compute instances.
  3. Add the following entries to the /etc/hosts file of the OCI WebLogic Server compute instances:
    #################################
# ALIASES on OCI for DR
#################################
virtual_IP_for_admin           virtualIP_fqdn virtualIP_hostname    ALIAS_OF_ADMINVHN
apphost1_compute_instance_IP  apphost1_fqdn   apphost1_hostname   ALIAS_OF_APPHOST1 
apphost2_compute_instance_IP  apphost2_fqdn   apphost2_hostname   ALIAS_OF_APPHOST2
    The following is an example of the /etc/hosts file in the secondary OCI WebLogic Server compute instance:
    #################################
# ALIASES on OCI for DR
#################################
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 WebLogic Server hosts:
    #################################
# ALIASES on-prem for DR
#################################
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 WebLogic Server hosts are added to the DNS resolver used by the VCN of the secondary mid-tier servers, pointing to the IP addresses of the secondary Oracle WebLogic Server hosts. This mode is valid when separate DNS servers are used in 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 all the /etc/hosts of all the Oracle WebLogic Server hosts.

The following are the steps to create the private view in the secondary VCN and resolve the virtual host names used by primary with the secondary IPs:

  1. In the OCI Console, go to secondary region and create the private view.
    1. Click Networking, DNS Management, Private Views, then Create Private View.
      For example, you can name the private view HYBRID_DR_VIRTUAL_HOSTNAMES
    2. Click Create Zone in the private view.
      For the zone name, you must use the complete domain of the virtual hosts. In this example: example.com.
    3. Add the virtual hosts names to this zone (short name), but resolved with secondary WLS hosts’ IPS.
    4. Click Publish changes.
  2. Add the private view to the secondary VCN resolver.
    1. Click the DNS resolver resource in the VCN.
    2. Add the DNS private view created previously.
      The hosts in the secondary VCN will resolve the virtual host names used by the primary Oracle WebLogic Server hosts using the private view.
  3. Validate the resolution SECONDARY hosts, by doing ping and nslookup of the virtual host names.
    They must be resolved with the equivalent SECONDARY IPs.

    Note:

    You can find Terraform code to create this OCI private view and records in Download Code.

Create and Configure the Virtual IP for the WebLogic Administration Server

For high availability, the WebLogic Administration Server must use a host name that is mapped to a virtual IP to allow failover across nodes.

Note:

Skip this task if you are not using a VIP address for the Administration Server in your primary system.

Assign an additional IP to the VNIC of the apphost1 compute instance. The additional IP is used by the Administration Server in the secondary Oracle Cloud Infrastructure (OCI) system. Although this IP will be normally attached to the apphost1 compute instance, it can be moved to the apphost2 compute instance to provide local failover for the Administration Server, as described in the EDG.

Once the new IP is attached to the VNIC using the OCI Console, it must be configured in the OS in a non-persistent mode (because this IP can be moved from apphost1 to apphost2 for admin server failover).

  1. Assign a new secondary private IP address to the VNIC of the apphost1 compute instance in OCI.
    Use the steps described in To assign a new secondary private IP to a VNIC of the OCI documentation.
    Provide a value in the host name that helps you to identify it as a virtual IP. For example, hydrwls-vip.
  2. Once the new IP is attached to the VNIC, configure the new IP address in the OS in a non-persistent mode.
    Use the steps described in Linux: Details about Secondary IP Addresses.
    This is required because the IP can move from apphosthost1 to apphosthost2 for admin server failover.
    1. View the network interfaces and the attached IP addresses of the apphosthost1 compute instance.
      In this example, the following is the primary IP of the VNIC: inet 100.70.10.13/20 brd 100.70.10.255 scope global dynamic ens3
      [opc@hydrwls1 ~]$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:00:17:00:05:87 brd ff:ff:ff:ff:ff:ff
    inet 100.70.10.13/20 brd 100.70.10.255 scope global dynamic ens3
       valid_lft 60218sec preferred_lft 60218sec
    inet6 fe80::200:17ff:fe00:587/64 scope link
       valid_lft forever preferred_lft forever
    2. As root, add the virtual IP to the interface as an additional IP by setting a sequence number in the label.
      [root@hydrwls1 ~]# ip addr add 100.70.10.20/20 dev ens3 label ens3:1
    3. Verify that the interface now has the new IP.
      In this example, the following is the secondary IP of the VNIC: inet 100.70.10.20/20 scope global secondary ens3:1 
      [root@hydrwls1 ~]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:00:17:00:05:87 brd ff:ff:ff:ff:ff:ff
    inet 100.70.10.13/20 brd 100.70.10.255 scope global dynamic ens3
       valid_lft 59873sec preferred_lft 59873sec
    inet 100.70.10.20/20 scope global secondary ens3:1
       valid_lft forever preferred_lft forever
    inet6 fe80::200:17ff:fe00:587/64 scope link
       valid_lft forever preferred_lft forever

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 the Oracle WebLogic Server.

  1. As the root user, check the status and the rules of the firewall service in each Oracle WebLogic Server compute instance.
    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 by the components of your system in each WebLogic Server compute instance.
    For example:
    firewall-cmd --permanent --add-port=7001/tcp
firewall-cmd --permanent --add-port=5556/tcp
firewall-cmd --permanent --add-port=8001/tcp
firewall-cmd --permanent --add-port=9001/tcp
service firewalld reload
  3. If you are using Coherence, then open tcp and udp for the Coherence cluster port (for example, 9991), for the ephemeral ports and tcp for port 7:
    Coherence requires you to open additional ports for Coherence Cluster communications. 
    sudo firewall-cmd --permanent --add-port=9991/udp
sudo firewall-cmd --permanent --add-port=9991/tcp
sudo firewall-cmd --permanent --add-port=32768-60999/udp
sudo firewall-cmd --permanent --add-port=32768-60999/tcp
sudo firewall-cmd --permanent --add-port=7/tcp
sudo service firewalld reload
  4. Check the status and the rules of the firewall service.
    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 5556/tcp 8001/tcp 9001/tcp 9991/tcp ...
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

Mount the OCI File Systems

The file systems that were previously created on Oracle Cloud Infrastructure (OCI) must be mounted in the Oracle WebLogic Server compute instances.

  1. Connect ssh to the WebLogic Server compute instances with opc user, and install the NFS client.
    sudo yum install nfs-utils
  2. Create the mount points in each of the WebLogic Server compute instances.
    For example, create directories for products, config, and runtime. Your values may differ. 
    sudo mkdir -p /u01/oracle/products
sudo mkdir -p /u01/oracle/config
sudo mkdir -p /u01/oracle/runtime
  3. As root user, add the entries to the /etc/fstab directory in the apphost1 compute instance.
    In the following example, 100.70.8.101 is the example value of the mount target’s IP address. If your OCI region has more than 1 availability domain and you have created more than one mount point, use the appropriate mount target IP for each export. 
    100.70.8.101:/export/wlsdrconfig	       /u01/oracle/config nfs defaults,nofail,nosuid,resvport 0 0
100.70.8.101:/export/wlsdrruntime          /u01/oracle/runtime nfs defaults,nofail,nosuid,resvport 0 0
100.70.8.101:/export/wlsdrproducts1        /u01/oracle/products nfs defaults,nofail,nosuid,resvport 0 0
  4. As root user, add the entries to the /etc/fstab directory in the apphost2 compute instance.
    In the following example, 100.70.8.101 is the example value of the mount target’s IP address. If your OCI region has more than 1 availability domain and you have created more than one mount point, use the appropriate mount target IP for each export. 
    100.70.8.101:/export/wlsdrconfig	        /u01/oracle/config nfs defaults,nofail,nosuid,resvport 0 0
100.70.8.101:/export/wlsdrruntime           /u01/oracle/runtime nfs defaults,nofail,nosuid,resvport 0 0
100.70.8.101:/export/wlsdrproducts2         /u01/oracle/products nfs defaults,nofail,nosuid,resvport 0 0
  5. As root user, mount the file systems in each wls compute instance:
    mount -a
  6. Verify that the file systems are correctly mounted.
    df -h
    The output for hydrwls1 and hydrwls2 should look similar to the following example:
    [root@hydrwls1 ~]# df -h
Filesystem                           Size  Used Avail Use% Mounted on
devtmpfs                              15G     0   15G   0% /dev
tmpfs                                 15G     0   15G   0% /dev/shm
tmpfs                                 15G   25M   15G   1% /run
tmpfs                                 15G     0   15G   0% /sys/fs/cgroup
/dev/sda3                             39G  4.4G   35G  12% /
/dev/sda1                            200M  7.4M  193M   4% /boot/efi
tmpfs                                3.0G     0  3.0G   0% /run/user/0
tmpfs                                3.0G     0  3.0G   0% /run/user/994
tmpfs                                3.0G     0  3.0G   0% /run/user/1000
100.70.8.101:/export/wlsdrconfig     8.0E     0  8.0E   0% /u01/oracle/config
100.70.8.101:/export/wlsdrruntime    8.0E     0  8.0E   0% /u01/oracle/runtime
100.70.8.101:/export/wlsdrproducts1  8.0E     0  8.0E   0% /u01/oracle/products
    [root@hydrwls2 ~]# df -h
Filesystem                          Size  Used Avail Use% Mounted on
devtmpfs                             15G     0   15G   0% /dev
tmpfs                                15G     0   15G   0% /dev/shm
tmpfs                                15G   25M   15G   1% /run
tmpfs                                15G     0   15G   0% /sys/fs/cgroup
/dev/sda3                            39G  4.4G   35G  12% /
/dev/sda1                           200M  7.4M  193M   4% /boot/efi
tmpfs                               3.0G     0  3.0G   0% /run/user/0
tmpfs                               3.0G     0  3.0G   0% /run/user/994
tmpfs                               3.0G     0  3.0G   0% /run/user/1000
100.70.8.101:/export/wlsdrconfig    8.0E     0  8.0E   0% /u01/oracle/config
100.70.8.101:/export/wlsdrruntime   8.0E     0  8.0E   0% /u01/oracle/runtime
100.70.8.101:/export/wlsdrproducts2  8.0E     0  8.0E   0% /u01/oracle/products
  7. Change the ownership of the folders to the oracle user and group.
    [root@hydrwls1 ~]#chown -R oracle:oinstall /u01/oracle/products
[root@hydrwls1 ~]#chown -R oracle:oinstall /u01/oracle/config
[root@hydrwls1 ~]#chown -R oracle:oinstall /u01/oracle/runtime
[root@hydrwls2 ~]#chown -R oracle:oinstall /u01/oracle/products
[root@hydrwls2 ~]#chown -R oracle:oinstall /u01/oracle/config
[root@hydrwls2 ~]#chown -R oracle:oinstall /u01/oracle/runtime
  8. Log in as the oracle user and verify that you can create files in these file systems. For the file systems that are shared (/u01/oracle/config, /u01/oracle/runtime) verify that when you create a file in one host it is visible from the other host.

Mount the OCI Block Volumes

Mount the Block Volumes that were previously created in the Oracle WebLogic Server compute instances.

For example,

Block Volume Compute Instance Mount Point
wlsdrBV1 hydrwls1 /u02
wlsdrBV2 hydrwls2 /u02
  1. SSH to all of the WebLogic Server hosts as root user, and create the folder that will be used as the mount point.
    [root@hydrwls1 ~]# mkdir -p /u02
  2. Connect to the Oracle Cloud Infrastructure (OCI) Console for your tenancy.
  3. Select the proper region.
  4. Open the navigation menu and click Storage, Block Storage, then click Block Volumes.
  5. Click on one of the Block Volumes.
  6. Click Attached Instances, then click Attach to Instance.
    1. Select iSCSI attachment type.
      IOPS performance is better with iSCSI attachments when compared to paravirtualized attachments.
    2. Select Read/Write access type.
    3. Select the appropriate compute instance.
  7. Attach to the compute instance.
  8. Once the volume is attached, click iSCSI Commands & Information in the Block Volume attachment to run the block volume's iSCSI commands.
    The iSCSI Commands and Information dialog box displays the iSCSI commands that you'll need. The commands are ready to use with the appropriate information included. You can copy and paste the commands into your compute instance session.
  9. List the volumes and identify the new one.
    For example:
    bash-4.2# lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sdb      8:16   0   50G  0 disk ------------> this is the new one
sda      8:0    0 46.6G  0 disk
├─sda2   8:2    0    8G  0 part [SWAP]
├─sda3   8:3    0 38.4G  0 part /
└─sda1   8:1    0  200M  0 part /boot/efi
  10. Format the new volume.
    For example:
    bash-4.2# mkfs.xfs -f /dev/sdb

meta-data=/dev/sdb               isize=256    agcount=4, agsize=3276800 blks
         =                       sectsz=4096  attr=2, projid32bit=1
         =                       crc=0        finobt=0, sparse=0, rmapbt=0
         =                       reflink=0
data     =                       bsize=4096   blocks=13107200, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=6400, version=2
         =                       sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
  11. Mount the volume.
    1. Use the command blkid to identify the UUID of the new block volume.
      For example:
      bash-4.2# blkid
/dev/sda3: UUID="1517ce80-df91-45cc-a27e-2aa38b3f6646" TYPE="xfs" PARTUUID="c42a8415-7230-42bb-970a-3b4c3142d279"
/dev/sda1: SEC_TYPE="msdos" UUID="A1E6-54F8" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="78756fd0-3be7-4fbb-b8a8-3d6f68a84b34"
/dev/sda2: UUID="5384ac33-8ffe-4ad8-8d40-6307f2756dc5" TYPE="swap" PARTUUID="0adbce70-6c26-44fd-bec5-c191a6f9e02f"
/dev/sdb: UUID="47955773-743f-4bde-bf2f-68ce0f71dbf9" TYPE="xfs"
    2. Edit the /etc/fstab file and add the line to mount the Block Volume.
      For example:
      UUID=47955773-743f-4bde-bf2f-68ce0f71dbf9 /u02 xfs defaults,_netdev,nofail 0 2
    3. Mount the block volume.
      bash-4.2# mount -a
    4. Verify that it is mounted.
      [opc@hydrwls1 ~]$ df -h
Filesystem                              Size  Used Avail Use% Mounted on
devtmpfs                                15G     0   15G   0% /dev
tmpfs                                   15G     0   15G   0% /dev/shm
tmpfs                                   15G  8.8M   15G   1% /run
…
/dev/sdb                                50G   33M   50G   1% /u02
…
  12. Once the Block Volume is mounted, change the ownership of the mount to the appropriate oracle user. 
    bash-4.2# chown oracle:oinstall /u02
  13. Reboot the host and verify that the block volume is automatically mounted after reboot.
  14. Repeat the steps to mount the block volumes in the rest of the secondary WebLogic Server hosts.
    For more information about attaching a volume, see the Oracle Cloud Infrastructure Documentation.

Create the TNS Alias

Create the TNS directory and tnsnames.ora file that point to the Oracle Cloud Infrastructure (OCI) DB System. Because the WebLogic domain configuration in the secondary will be a copy of the primary, you must create the same artifacts that are in the primary to use the TNS alias approach in the WebLogic datasources.

  1. As the oracle user, create the tns folder in each WebLogic Server compute instance, using the same path that is used in the primary mid-tier hosts.
    This should be a local folder that is not replicated from the primary. 
    [oracle@hydrwls1 ~]$ mkdir -p /home/oracle/tnsnames_dir
[oracle@hydrwls2 ~]$ mkdir -p /home/oracle/tnsnames_dir
  2. Create a tnsnames.ora file in the directory with the same tns alias that is used in the primary, but pointing to the address of the OCI DB System.

    The service name should be the same in the primary and secondary.

    MYPDBSERVICE =
(DESCRIPTION=
  (ADDRESS_LIST=
    (LOAD_BALANCE=ON)
    (ADDRESS=(PROTOCOL=TCP)(HOST=hydrdb-scan.dbTierSubnet.hydrvcn.oraclevcn.com)(PORT=1521))
  )
  (CONNECT_DATA=(SERVICE_NAME=mypdbservice.example.com))
)

Create the oracle User Environment Variables

It's common to have WebLogic-related environment variables in the oracle user’s profile in the WebLogic hosts. For example, ORACLE_HOME, JDK_HOME, PATH, ASERVER_HOME, and others.

  1. Review the oracle user’s profiles files in the primary WebLogic Server hosts.
  2. In secondary, add the same WebLogic related environment variables to the oracle user’s profile files (.bashrc, or .bash_profile).

    Note:

    The oracle user’s .bashrc file in the secondary WebLogic Server hosts may already contain variables defined (such as MIDDLEWARE_HOME, WLS_HOME, and others), but they probably do no match your environment’s folders and are not valid for you. Make sure you remove or modify them accordingly to your environment folders.