Replicate the File System Artifacts to OCI

The secondary mid-tiers must have a replica of the artifacts used by the SOA domain in primary. The artifacts can be static or dynamic, depending on how frequently they are modified. As part of the DR setup, an initial replication of the artifacts must be done. This initial replica is refreshed during the lifecycle of the system.

About Artifacts

Determine the type of artifacts you need to replicate.

• Static artifacts: are files and directories that do not change frequently. These include:
  • Oracle Home: usually consists of an Oracle home and an Oracle WebLogic Server home. Oracle Fusion Middleware allows you to create multiple Oracle WebLogic Server Managed Servers from one single binary file installation. You can install binary files in a single location on a shared storage and reuse this installation by servers in different nodes. For maximum availability, Oracle recommends that you use redundant binary installations.
  • Oracle Inventory: The orainventory is a folder that contains a list of the existing Oracle Homes, and it is located in a separated folder separated from the Oracle Home. The /etc/oraInst.loc file determines which is the location of the orainventory.
• Dynamic artifacts: are files that change frequently. These artifacts include:
  • Domain home: Domain directories of the Administration Server and the Managed Servers. In an EDG topology, the ASERVER_HOME is in a shared location, and the MSERVER_HOME is in a private location and each server has its own MSERVER_HOME (although it can be stored in an NFS too).
  • Application artifacts, such as .ear or .war files.
  • Database artifacts, such as the MDS repository and SOAINFRA schemas.
  • Persistent stores, such as JMS providers and transaction logs. Oracle recommends storing these artifacts in the database. This is the approach recommended in the EDG topology, and especially useful for disaster recovery (DR) environments, because they are automatically replicated to the standby site through the underlying Oracle Data Guard.
  • Deployment plans, used for updating technology adapters, such as file and JMS adapters. They need to be saved in a location that is accessible to all nodes in the cluster that the artifacts are being deployed to.
  • Other runtime artifacts, such as files used by file adapters, files transferred by MFT, or other custom runtime artifacts.

All content that resides in the database (such as the MDS repository, SOAINFRA schemas, JMS and TLOGs, and custom data) is automatically replicated to the secondary site through Oracle Data Guard.

To replicate the content that resides in the file system (such as Oracle Home and the WebLogic Domain configuration) in a disaster recovery topology, you can use different approaches. The most common ones are storage level replication, rsync-based replica, or DBFS-based replica.

The Hybrid DR model, described here, is where the primary is in on-premises and the secondary is in OCI. Storage level replication isn't available in the hybrid DR model. Instead, rsync is the recommended approach to replicate the artifacts from primary to standby. You can use Oracle Database File System (DBFS)-based replica to replicate some artifacts, see details in About Oracle Database File System in Learn More.

Identify the Folders and File System Artifacts

Identify the NFS volumes and folders used by the primary SOA hosts of the primary environment and its content.

The following tables provide an example of the primary file system artifacts used in this example.

File System Volume	Host	Mount Point Folder	Comments	Type of Artifact
NFS VOLFMW1 /export/soa/products1	SOAHOST1	/u01/oracle/products	Volume for the JDK and FMW binary files.	Static
NFS VOLFMW2 /export/soa/products2	SOAHOST2	/u01/oracle/products	Volume for the JDK and FMW binary files.	Static
NFS VOLADMIN/export/soa/config	SOAHOST1, SOAHOST2	/u01/oracle/config	Volume for Administration Server domain directory and other shared configurations, such as Deployment Plans, applications, and keystores.	Dynamic
LOCAL* /u02/oracle/config	SOAHOST1	/u02/oracle/config	Volume for private config in SOAHOST1	Dynamic
LOCAL* /u02/oracle/config	SOAHOST2	/u02/oracle/config	Volume for private config in SOAHOST2	Dynamic
NFS VOLRUNTIME /export/soa/runtime	SOAHOST1, SOAHOST2	/u01/oracle/runtime	Volume for shared runtime content, like files used by file adapters, and other runtime artifacts. Note: it is recommended to store JMS messages and TLOGS in the database, using JDBC persistent stores, instead of in this folder.	Dynamic

* The local file system volumes can be private (non-shared) mounts in NFS instead of local storage.

The following table is an example of the EDG variables for folder locations.

EDG Variables	Value
ORACLE_BASE	/u01/oracle/products
ORACLE_HOME	/u01/oracle/products/fmw
JAVA_HOME	/u01/oracle/products/jdk
SHARED_CONFIG_DIR	/u01/oracle/config
APPLICATION_HOME	/u01/oracle/config/applications/mysoadomain
DEPLOY_PLAN_HOME	/u01/oracle/config/dp
KEYSTORE_HOME	/u01/oracle/config/keystores
ASERVER_HOME	/u01/oracle/config/domains/mysoadomain
PRIVATE_CONFIG_DIR	/u02/oracle/config
MSERVER_HOME	/u02/oracle/config/domains/mysoadomain
NM_HOME	/u02/oracle/config/nodemanager
ORACLE_RUNTIME	/u01/oracle/runtime

Verify Connectivity Between the Primary and Standby Hosts

The primary SOA hosts must connect to the remote standby Oracle Cloud Infrastructure (OCI) SOA hosts, and vice versa,

The physical names of the remote SOA hosts can be resolvable in DNS, or you can include the remote peer SOA hosts physical names and IPs in the /etc/hosts files. That is, add the secondary SOA hosts physical names and their IPs to the /etc/hosts file of the primary SOA hosts. Similarly, add the primary SOA hosts physical names and their IPs to the /etc/hosts file of the secondary SOA hosts.

Note:

If the primary is not using virtual host names and it uses the physical node host names as the listen addresses for the servers, then do not perform these steps. Because in that scenario, the primary physical node host names should be resolved by the OCI SOA hosts IPs in standby. In that scenario, instead of performing the following steps, use the hosts’ IPs for connecting with SSH to the remote nodes.

1. Edit the /etc/hosts file in the primary on-premises SOA hosts to include the remote peer SOA hosts physical names and IP addresses.
   The following is an example of the aliases on the on-premises hosts.

   
   #################################
   # 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              SOAHOST1.example.com    SOAHOST1
   10.10.10.14   host4.myopnnetwork.com       host4              SOAHOST2.example.com    SOAHOST2
   # Front-end name (resolved but primary Load Balancer IP
   10.10.10.100    mysoa.example.com
   # Remote OCI soa hosts physical names (without virtual host name aliases!)
   100.70.10.13    hydrsoa1.midTiersubnet.hydrvcn.oraclevcn.com      hydrsoa1        
   100.70.10.14   hydrsoa2.midTiersubnet.hydrvcn.oraclevcn.com       hydrsoa2

2. Edit the /etc/hosts file in the standby OCI SOA hosts to include the remote, on-premises SOA hosts physical names. Don't include the virtual host name aliases.
   The following is an example of the aliases on the standby OCI SOA hosts.

   #################################
   # ALIASES in OCI
   #################################
   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
   # Front-end name (resolved by secondary OCI LBR IP)
   1070.70.70    mysoa.example.com
   # Remote on-prem soa hosts physical names (without virtual host name aliases!)
   10.10.10.13   host3.myopnnetwork.com       host3
   10.10.10.14   host4.myopnnetwork.com       host4

3. Use the SSH command to verify cross-connectivity from the primary, on-premises SOA hosts to the secondary OCI SOA hosts.
   An ssh key is required when connecting to OCI compute instances.

   ssh -i my_private_key [e-mail]
   ssh -i my_private_key [e-mail]

4. Use the SSH command to verify the cross-connectivity between the secondary OCI SOA hosts and the primary, on-premises SOA hosts.
   An ssh key may be not required.

   ssh  [e-mail]
   ssh  [e-mail]

Duplicate the Folder Structure in the Secondary OCI Hosts

At this point, the Oracle Cloud Infrastructure (OCI) SOA compute instances already have the FSS mounted. Before replicating the content, create the appropriate folder structure for the EDG.

The following example shows the commands to create the EDG folder structure that is used by the EDG environment of this document.

1. As an oracle user, create the folders in OCI SOAHOST1.

   mkdir -p  /u01/oracle/products/fmw
   mkdir -p  /u01/oracle/products/jdk
   mkdir -p  /u01/oracle/products/oraInventory
   mkdir -p /u02/oracle/config
   mkdir -p /u01/oracle/config/domains/mysoadomain
   mkdir -p /u01/oracle/config/applications/mysoadomain
   mkdir -p /u01/oracle/config/dp/mysoadomain
   mkdir -p /u01/oracle/config/keystores

2. As an oracle user, create the folders in OCI SOAHOST2.

   mkdir -p  /u01/oracle/products/fmw
   mkdir -p  /u01/oracle/products/jdk
   mkdir -p  /u01/oracle/products/oraInventory
   mkdir -p /u02/oracle/config

Copy ORACLE_HOME and JAVA_HOME to the Secondary Hosts

Copy ORACLE_HOME and JAVA_HOME from the primary hosts to the secondary hosts.

ORACLE_HOME and JAVA_HOME are normally under the same products folder, along with oraInventory. See Identify the Folders and File System Artifacts for the locations that you identified earlier.

1. Copy the products folder from the on-premises primary SOAHOST1 to the remote SOAHOST1.
2. Copy the products home folder from the on-premises primary SOAHOST2 and save it to remote SOAHOST2. Repeat for any other compute instances.
3. Copy the /etc/oraInst.loc file from the primary 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.

   In the example provided, oraInventory is under /u01/oracle/products and it's copied along with the jdk and Oracle home. If your oraInventory is in a different location, ensure that you also copy it to the secondary hosts.

   Note:

   You can find an example script that uses rsync to copy the products folder from the on-premises primary SOAHOST1 to the remote SOAHOST1 in Download Code. Repeat the same to copy the products home to the rest of the secondary compute instances (that is, from SOAHOST2 to remote SOAHOST2).

Copy the WebLogic Domain Configuration Folders to the Standby Hosts

Copy the WebLogic Domain shared configuration folder and private configuration folder to the Oracle Cloud Infrastructure (OCI) SOA hosts.

1. Copy the WebLogic Domain shared configuration folder from the on-premises primary SOAHOST1 to the remote OCI SOAHOST1.
   The WebLogic Domain shared configuration resides in the location designed by the SHARED_CONFIG_DIR variable and it includes the shared configuration folders like APPLICATION_HOME, DEPLOY_PLAN_HOME, KEYSTORE_HOME and ASERVER_HOME.

   Note:

   You can copy the shared configuration folder from the on-premises primary SOAHOST1 to remote SOAHOST1. This is a shared folder, so you just need to copy it to one of the OCI SOA hosts.

   An example script is available in Download Code.

2. Copy the WebLogic Domain private configuration folder of the on-premises primary SOAHOST1 and save it to remote OCI SOAHOST1
   The WebLogic private configuration resides in the location specified by the variable PRIVATE_CONFIG_DIR, and it contains the MSERVER_HOME and the NM_HOME folders. These folders are not shared, they're specific (private) to each SOA host. Therefore, you must perform the copy for each server – you must copy the private config of on-premises SOAHOST1 to OCI SOAHOST1, the private config of the on-premises SOAHOST2 to the OCI SOAHOST2, and so on.

   Note:

   In Download Code, you can find an example script that uses rsync to copy the private configuration folder from the on-premises primary SOAHOST1 to the remote SOAHOST1.

Copy the Shared Runtime Folder

Copy the shared runtime folder to the Oracle Cloud Infrastructure (OCI) SOA hosts, if needed.

The shared runtime folder resides in the location specified by the variable ORACLE_RUNTIME. See Identify the Folders and File System Artifacts for the locations that you identified earlier.

Note:

It is recommended to store the JMS persistent stores and TLOGS stores in the database, using JDBC persistent stores. Since they are in the database, they are automatically replicated to secondary system with Oracle Data Guard.

• As this is runtime information, you don't normally need to replicate it during the set up phase. However, if you do need to replicate this folder to the standby hosts, then you can copy the content following a similar approach that you used to copy the WebLogic Domain shared configuration file.