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 SOA Mid-tier Nodes

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

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
hydrsoa1	HyDRCompmt	AD1	Oracle Linux 7.9	VM.Standard2.2	hydrvcn	midTierSubnet
hydrsoa2	HyDRCompmt	AD1	Oracle Linux 7.9	VM.Standard2.2	hydrvcn	midTierSubnet

1. Connect to the OCI Console for your tenancy.
2. Select the proper region.
3. Open the navigation menu and click Compute, then click Create Instance.
4. Select the compartment to create the instance in.
5. Select the VCN, subnet, and Availability Domain of your environment.
   If the OCI Region has more than one Availability Domain, then place the Oracle SOA Suite compute instances in different Availability Domains.
6. Select the OS image and shape that fits your requirements.
7. 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

Create the same user and group used by the primary on-premises Oracle software. The user and group identifiers (IDs) must be the same as those in the primary environment.

You can use SSH to access your recently created instances as the opc user. This user has sudo privileges and can be used to create additional users and groups. You need to create the same user and group used by primary on-premises for the oracle software, making sure that the user and group IDs are the same as in primary.

This example uses the typical users and groups in an EDG environment, as shown in the table.

User or Group	Name	Description
User	nobody	An unprivileged user
	oracle	The owner of Oracle software (you could be using a different name). The primary group for this account must be oinstall. The account must also be in the dba group.
Groups	oinstall	Principal group of the oracle user
	dba	Secondary group of the oracle user

Create users and groups in the secondary compute instances. Create the same user and group used by primary on-premises for the Oracle software, making sure that the user and group IDs are the same as in primary.

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 IDs in the primary host.
   1. Log into an on-premises Oracle SOA Suite host with the oracle user, then use the command id to identify the groups and IDs of the user.

      [[e-mail] ~]$ id
      uid=1001(oracle) gid=1002(oinstall) groups=1002(oinstall),1001(dba)
       [oracle@ host3.myopnetwork.com ~]$ more /etc/passwd | grep nobody
      nobody:x:99:99:Nobody:/:/bin/false
      [oracle@ host3.myopnetwork.com ~]$ more /etc/passwd | grep oracle
      oracle:x:1001:1002::/home/oracle:/bin/bash

   2. Check to see if any of the users and group already exist in the OCI compute instances.

      [opc@hydrsoa1 ~]$ more /etc/passwd | grep 1001
      [opc@hydrsoa1 ~]$ more /etc/group | grep 1001
      [opc@hydrsoa1 ~]$ more /etc/group | grep 1002

   3. Check to see if any of the users and group IDs already exist in the OCI compute instances.

      [[e-mail] ~]$ id
      uid=1001(oracle) gid=1002(oinstall) groups=1002(oinstall),1001(dba)
       [oracle@ host3.myopnetwork.com ~]$ more /etc/passwd | grep nobody
      nobody:x:99:99:Nobody:/:/bin/false
      [oracle@ host3.myopnetwork.com ~]$ more /etc/passwd | grep oracle
      oracle:x:1001:1002::/home/oracle:/bin/bash
      

      It is not expected to have any Oracle related user or groups already created in the OCI SOA compute instances. Normally, only the user nobody already exists. Therefore, you can use the IDs from the primary in the secondary.
2. Create the group and user in each OCI SOA compute instance using the same user and group IDs as the primary hosts.
   For example,

   sudo -s
   groupadd oinstall -g 1002
   groupadd dba -g 1001
   useradd -u 1001 oracle -g oinstall -G dba

3. (Optional recommended) Enable SSH access to the newly created oracle user.
   Enabling SSH access to the newly created oracle user is optional, but highly recommended. It is useful in this DR topology because it allows the oracle user a direct connection to the commands that are used to copy the filesystem artifacts.
   1. Copy the public key that you use to connect to the SOA 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 /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. Change the permissions of the authorized_keys file to grant the oracle user full read and write access to the file (600).

      chmod 600 /home/oracle/.ssh/authorized_keys

   7. Verify the connection by connecting with SSH using the oracle user and your private key.

Prepare the Operating System Requirements

The secondary mid-tier hosts must meet the operating system requirements to run the software.

For the Oracle SOA Suite and Oracle WebLogic Server binaries to run properly, you must prepare the operating systems for the standby systems the same way that they were prepared in the primary when the software was installed.

The binaries of the SOA homes are copied from the primary SOA hosts to the secondary SOA hosts. Therefore, it isn't necessary to run the runinstaller in the secondary SOA hosts. However, the operating system requirements must be the same.

1. Ensure that your environment meets the minimum installation requirements for the products that are installed in primary SOA hosts.
   Check the corresponding document in the Oracle Fusion Middleware System Requirements and Specifications and the step Verifying Linux Operating System Requirements from the EDG.
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 SOA hosts and set the values in the OCI SOA 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) SOA 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 SOA 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 SOA 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 SOA compute instances.
3. Add the following entries to the /etc/hosts file of the OCI SOA compute instances:

   #################################
   # ALIASES on OCI for DR
   #################################
   virtual_IP_for_admin           virtualIP_fqdn virtualIP_hostname    ALIAS_OF_ADMINVHN
   soahost1_compute_instance_IP  soahost1_fqdn   soahost1_hostname   ALIAS_OF_SOAHOST1 
   soahost2_compute_instance_IP  soahost2_fqdn   soahost2_hostname   ALIAS_OF_SOAHOST2    
   

   The following is an example of the /etc/hosts file in the secondary OCI SOA compute instance:

   #################################
   # ALIASES on OCI for DR
   #################################
   100.70.10.20   hydrsoa-vip.midTiersubnet.hydrvcn.oraclevcn.com    hydrsoa-vip       ADMINVHN.example.com   ADMINVHN
   100.70.10.13   hydrsoa1.midTiersubnet.hydrvcn.oraclevcn.com       hydrsoa1          SOAHOST1.example.com   SOAHOST1
   100.70.10.14   hydrsoa2.midTiersubnet.hydrvcn.oraclevcn.com       hydrsoa2          SOAHOST2.example.com   SOAHOST2

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 soahost1 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 soahost1 compute instance, it can be moved to the soahost2 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 soahost1 to soahost2 for admin server failover).

1. Assign a new secondary private IP address to the VNIC of the soahost1 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, hydrsoa-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 soahosthost1 to soahosthost2 for admin server failover.
   1. View the network interfaces and the attached IP addresses of the soahosthost1 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@hydrsoa1 ~]$ 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@hydrsoa1 ~]# 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@hydrsoa1 ~]# 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 SOA Suite 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 SOA compute instance.
   For example:

   firewall-cmd --permanent --add-port=7001/tcp
   firewall-cmd --permanent --add-port=5556/tcp
   firewall-cmd --permanent --add-port=7010/tcp
   firewall-cmd --permanent --add-port=8001/tcp
   firewall-cmd --permanent --add-port=8011/tcp
   firewall-cmd --permanent --add-port=8021/tcp
   firewall-cmd --permanent --add-port=9001/tcp
   firewall-cmd --permanent --add-port=7801/tcp
   firewall-cmd --permanent --add-port=7801/udp
   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 SOA Suite compute instances.

1. Connect ssh to the SOA compute instances with opc user, and install the NFS client.

   sudo yum install nfs-utils

2. Create the mount points in each of the SOA 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 soahost1 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/soadrconfig	       /u01/oracle/config nfs defaults,nofail,nosuid,resvport 0 0
   100.70.8.101:/export/soadrruntime          /u01/oracle/runtime nfs defaults,nofail,nosuid,resvport 0 0
   100.70.8.101:/export/soadrproducts1        /u01/oracle/products nfs defaults,nofail,nosuid,resvport 0 0

4. As root user, add the entries to the /etc/fstab directory in the soahost2 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/soadrconfig	        /u01/oracle/config nfs defaults,nofail,nosuid,resvport 0 0
   100.70.8.101:/export/soadrruntime           /u01/oracle/runtime nfs defaults,nofail,nosuid,resvport 0 0
   100.70.8.101:/export/soadrproducts2         /u01/oracle/products nfs defaults,nofail,nosuid,resvport 0 0

5. As root user, mount the file systems in each soa compute instance:

   mount -a 

6. Verify that the file systems are correctly mounted.

   df -h

   The output for hydrsoa1 and hydrsoa2 should look similar to the following example:

   [root@hydrsoa1 ~]# 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/soadrconfig     8.0E     0  8.0E   0% /u01/oracle/config
   100.70.8.101:/export/soadrruntime    8.0E     0  8.0E   0% /u01/oracle/runtime
   100.70.8.101:/export/soadrproducts1  8.0E     0  8.0E   0% /u01/oracle/products

   [root@hydrsoa2 ~]# 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/soadrconfig    8.0E     0  8.0E   0% /u01/oracle/config
   100.70.8.101:/export/soadrruntime   8.0E     0  8.0E   0% /u01/oracle/runtime
   100.70.8.101:/export/soadrproducts2  8.0E     0  8.0E   0% /u01/oracle/products

7. Change the ownership of the folders to the oracle user and group.

   [root@hydrsoa1 ~]#chown -R oracle:oinstall /u01/oracle/products
   [root@hydrsoa1 ~]#chown -R oracle:oinstall /u01/oracle/config
   [root@hydrsoa1 ~]#chown -R oracle:oinstall /u01/oracle/runtime
   [root@hydrsoa2 ~]#chown -R oracle:oinstall /u01/oracle/products
   [root@hydrsoa2 ~]#chown -R oracle:oinstall /u01/oracle/config
   [root@hydrsoa2 ~]#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 SOA Suite compute instances.

For example,

Block Volume	Compute Instance	Mount Point
soadrBV1	hydrsoa1	/u02
soadrBV2	hydrsoa2	/u02

1. SSH to all of the SOA hosts as root user, and create the folder that will be used as the mount point.

   [root@hydrsoa1 ~]# 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@hydrsoa1 ~]$ 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 SOA 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 SOA 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@hydrsoa1 ~]$ mkdir -p /home/oracle/tnsnames_dir
   [oracle@hydrsoa2 ~]$ 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.

   SOAPDB =
   (DESCRIPTION=
     (ADDRESS_LIST=
       (LOAD_BALANCE=ON)
       (ADDRESS=(PROTOCOL=TCP)(HOST=hydrdb-scan.dbTierSubnet.hydrvcn.oraclevcn.com)(PORT=1521))
     )
     (CONNECT_DATA=(SERVICE_NAME=soapdb.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 SOA 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 SOA 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.