Replicate the File System Artifacts to OCI
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 theorainventory
.
- 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 application 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, application 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 WebLogic Server 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/wls/products1 |
APPHOST1 | /u01/oracle/products |
Volume for the JDK and FMW binary files. | Static |
NFS VOLFMW2 /export/wls/products2 |
APPHOST2 | /u01/oracle/products |
Volume for the JDK and FMW binary files. | Static |
NFS VOLADMIN/export/wls/config |
APPHOST1, APPHOST2 | /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 |
APPHOST1 | /u02/oracle/config |
Volume for private config in APPHOST1 | Dynamic |
LOCAL*
/u02/oracle/config |
APPHOST2 | /u02/oracle/config |
Volume for private config in APPHOST2 | Dynamic |
NFS VOLRUNTIME /export/wls/runtime |
APPHOST1, APPHOST2 | /u01/oracle/runtime |
Volume for shared runtime content, like files used by file adapters, and other runtime artifacts. Note: it is recommended to store
|
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/mydomain |
DEPLOY_PLAN_HOME |
/u01/oracle/config/dp |
KEYSTORE_HOME |
/u01/oracle/config/keystores |
ASERVER_HOME |
/u01/oracle/config/domains/mydomain |
PRIVATE_CONFIG_DIR |
/u02/oracle/config |
MSERVER_HOME |
/u02/oracle/config/domains/mydomain |
NM_HOME |
/u02/oracle/config/nodemanager |
ORACLE_RUNTIME |
/u01/oracle/runtime |
Verify Connectivity Between the Primary and Standby Hosts
The primary WebLogic Server hosts must connect to the remote standby Oracle Cloud Infrastructure (OCI) WebLogic Server hosts, and vice versa,
The physical names of the remote WebLogic
Server hosts can be
resolvable in DNS, or you can include the remote peer WebLogic
Server hosts
physical names and IPs in the /etc/hosts
files.
That is, add the secondary WebLogic
Server hosts physical names and their IPs to the
/etc/hosts
file of the primary WebLogic
Server hosts.
Similarly, add the primary WebLogic
Server hosts physical names and their IPs to the
/etc/hosts
file of the secondary WebLogic
Server 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 WebLogic Server 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.Duplicate the Folder Structure in the Secondary OCI Hosts
At this point, the Oracle Cloud Infrastructure (OCI) WebLogic Server compute instances already have the FSS mounted. Before replicating the content, create the appropriate folder structure for the EDG.
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.
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) WebLogic Server hosts.
Copy the Shared Runtime Folder
Copy the shared runtime folder to the Oracle Cloud Infrastructure (OCI) WebLogic Server 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.