Mid-Tier Replication

There are various replication technologies and methods for ongoing replication of the mid-tier file artifacts. The scenarios described here assume that the mid-tier file system artifacts, such as the config and products folders, are already available in the secondary mid-tier.

It doesn’t matter if you copied them using a particular technology during the DR setup. You can use a different approach for subsequent replications throughout the lifecycle.

For documentation and illustration purposes, most of the examples focus on an Oracle WebLogic Server system, where the primary is a WLS for OCI stack, and the secondary system has been created using the WLS-HYDR framework. As an example of managing the site’s specific information, the implementations also handle the database connection string for the mid-tier, assuming that the Oracle WebLogic Server environment uses a TNS alias to connect to the database.

Mid-Tier File Artifacts

Ideally, you should replicate all files involved in the mid-tier system from primary to secondary at the same point in time.

However, different file types may need different replication frequencies to simplify management costs and to reduce the total cost of ownership of a disaster protection system. This is important when you design the volumes and file systems that you want to use for replication. Some artifacts are static, whereas others are dynamic.

  • Product artifacts

    Product artifacts are the directory or directories into which the mid-tier software is installed.

    It is not mandatory to install the software at the secondary site. When the production site storage is replicated to the secondary site storage, the software installed on the production site volumes is replicated to the secondary site volumes.

    A secondary system must behave exactly as the primary when a failover or switchover occurs. It should admit patches and upgrades as a first-class installation. This means that when a failover or switchover occurs, the secondary system must use a standard inventory for patches and upgrades.

    The product artifacts are static and typically require a low RTO. You aren't required to copy them across regions frequently, because they change only when patches and fixes are applied.

    Tip:

    For example, in an Oracle WebLogic Server system, the product artifact is the Oracle Home, where all Oracle software is installed and is referenced by FMW and Oracle WebLogic environment variables. To maintain consistency, you must replicate the Oracle Inventory with the same frequency as the Oracle Homes used by the different FMW components. The Oracle Inventory includes oraInst.loc and oratab files, which are located in the /etc directory.

  • Configuration Artifacts

    The configuration artifacts contain the mid-tier’s configuration and are files that change frequently. Configuration artifacts change frequently, depending on application updates. They require a low RTO and a high replication frequency.

    Tip:

    For example, in a WebLogic or FMW system, the configuration artifacts include the following:
    • WebLogic Domain home: Domain directories of the Administration Server and the Managed Servers.
    • Oracle instances of system components such as Oracle HTTP Server: Oracle Instance home directories.
    • Application artifacts, such as .ear or .war files.
    • Database artifacts, such as the MDS repository and the JDBC persistent stores definitions.
    • Deployment plans that are used for updating technology adapters, such as file and JMS adapters. They must be saved in a location that is accessible to all nodes in the cluster to which the artifacts are being deployed.

    It is important to maintain the consistency for configuration artifacts across different stores; otherwise, applications may stop working after a restore.

    Tip:

    For example, WebLogic Domain configuration reflecting a new JMS server must be aligned with the Database table that it uses as a persistent store. Replicating only the WebLogic domain configuration without replicating the pertaining table will cause an Oracle WebLogic Server failure.
  • Runtime Artifacts

    Runtime artifacts are files generated by applications at runtime.

    These files may change very frequently. Their RTO and RPO are purely driven by business needs. In some cases, these artifacts may need to be discarded after a short time. For example, a bid order that expires in a short period. In other cases, these files may contain transactional records of operations completed by an application that need to be preserved. How frequently they need to be replicated and how important it is to preserve these files in a disaster event is usually a business-driven decision.

    Tip:

    In a WebLogic system, examples of runtime artifacts are the files generated by SOA’s File or FTP Adapters, the files managed by Oracle MFT, or any other information that applications generate through their business logic and that is stored directly on the file system.

    The following table is a summary of the recommendations for replicating file system artifacts during the lifecycle:

    Mid-Tier File Artifact Examples in WebLogic System Replication Frequency and Recommendations
    Product artifacts FMW home, JDK, inventory Low replication frequency or under demand (for example, after patching). Alternatively, you can also not replicate products and maintain them separately to test the patches in a standby environment first.
    Configuration artifacts WebLogic domain, Oracle instances, applications, deployment plans, keystores The frequency depends on how often the configuration changes are performed. High replication frequency is normally required.
    Runtime artifacts Files generated by the File and FTP Adapters Determined by the business requirements.