D Using Peer to Peer File Copy for Testing

As an alternative to using disk replication technology for disaster protection and disaster recovery of Oracle Application Server middle tier components, you can use peer to peer file copy mechanisms in test environments to replicate middle tier file system data from a production site host to a standby site peer host in an Oracle Application Server Disaster Recovery topology. An example of a peer to peer file copy mechanism is rsync (an open source utility for UNIX systems).

This appendix describes how to use rsync instead of disk replication in your Oracle Application Server Disaster Recovery topology. This appendix discusses rsync in the context of symmetric topologies. For more information about symmetric topologies, refer to Appendix C, "Creating an Asymmetric Topology." The information provided for rsync in this appendix also applies to other peer to peer file copy mechanisms.

Before you read this appendix, read the rest of this manual to ensure that you are familiar with how to use disk replication and Oracle Data Guard in an Oracle Application Server Disaster Recovery topology. There are many similarities between using disk replication and rsync for disaster protection and disaster recovery of your Oracle Application Server components.

Note:

You can use rsync instead of disk replication technology to replicate middle tier file system data from the production site to the standby site. However, be aware that the following beneficial disk replication features are not available when you use rsync:

With disk replication, you can roll changes back to the point in time when any previous snapshot was taken at the production site.

With rsync, replicated production site data overwrites the standby site data, and you cannot roll back a replication.
With disk replication, the volume you set up for each host cluster in the shared storage systems ensures data consistency for that host cluster across the production site's shared storage system and the standby site's shared storage system.

With rsync, data consistency is not guaranteed.

Because of these deficiencies in comparison to disk replication, rsync is not supported for disaster recovery use in actual production environments.

D.1 Using rsync and Oracle Data Guard for Oracle Application Server Disaster Recovery Topologies

These two basic principles apply when you use rsync and Oracle Data Guard to provide disaster protection and disaster recovery for your Oracle Application Server Disaster Recovery topology:

Use rsync for disaster protection of your Oracle Application Server middle tier components.
Use Oracle Data Guard for disaster protection of Oracle databases that are used in your Oracle Application Server topology. Appendix A, "Using Databases in the OracleAS Disaster Recovery Solution" describes how to set up Oracle Data Guard to provide disaster recovery for Oracle database.

D.1.1 Using rsync for Oracle Application Server Middle Tier Components

Follow these steps to use rsync to provide disaster protection and disaster recovery for your Oracle Application Server middle tier components:

Set up rsync to enable replication of files from a production site host to its standby site peer host. See the rsync man page for instructions on installing and setting up rsync, and for syntax and usage information. Information about rsync is also available at http://rsync.samba.org.
For each production site host on which one or more Oracle Application Server components has been installed, set up rsync to copy the following directories and files to the same directories and files on the standby site peer host:
- The Oracle Application Server home directory and subdirectories, and all the files in them.
- The Oracle Central Inventory directory and files for the host, which includes the Oracle Universal Installer entries for the Oracle Application Server installations.
- If applicable, the Oracle Application Server static HTML pages directory for the Oracle HTTP Server installations on the host.
- If applicable, the .fmb and .fmx deployment artifact files created by Oracle Forms on the host, and the .rdf deployment artifact files created by Oracle Reports on the host.
  
  Note:
  Run rsync as root. If you want rsync to work without prompting users for a password, set up SSH keys between the production site host and standby site host, so that SSH does not prompt for a password.
Set up scheduled jobs, for example, cron jobs, for the production site hosts for which you set up rsync in the previous step. These scheduled jobs enable rsync to automatically perform replication of these files from the production site hosts to the standby site hosts on a regular interval. An interval of once a day is recommended for a production site where the Oracle Application Server configuration does not change very often.
Whenever a change is made to the configuration of an Oracle Application Server middle tier configuration on a production site host (for example, when a new application is deployed), you should perform a manual synchronization of that host with its standby site peer host using rsync.
Whenever you perform a manual rsync synchronization of an Oracle Application Server middle tier instance on a production site host to the peer standby site host, you should also manually force a synchronization of any associated database repository for the production site's Oracle Application Server instance to the standby site using Oracle Data Guard. See Section A.5, "Manually Forcing Database Synchronization with Oracle Data Guard" for more information on manually forcing a synchronization of an Oracle database using Oracle Data Guard.

D.1.2 Performing Failover and Switchover Operations

Follow these steps to perform a failover or switchover from the production site to the standby site when you are using rsync:

Shut down any processes still running on the production site (if applicable).
Stop the rsync jobs between the production site hosts and their standby site peer hosts.
Use Oracle Data Guard to fail over the production site databases to the standby site.
Your production site hosts may include Oracle Application Server instances from different Oracle Application Server releases, such as release 10.1.2.x and 10.1.3.x. For any OC4J instances from Oracle Application Server 10.1.3.x releases, download and run the script provided with OracleMetaLink patch 6785728 in the Oracle home directories for the 10.1.3.x OC4J instances to remove persistent OC4J lock files. The URL for OracleMetaLink is:

https://metalink.oracle.com

Note:
Run the script in the Oracle homes for 10.1.3.x OC4J instances only.
On the standby site, manually start the processes for the Oracle Application Server instances.
Route all user requests to the standby site (using a global DNS push or by updating the global load balancer).
Use a browser client to perform post-failover or post-switchover testing to confirm that requests are being resolved at the standby site (current production site).

After these steps have been performed, the former standby site has become the currrent production site. At this point, any issues that caused the original production site to become unavailable can be examined. Then work can begin on resolving those issues so that the original production site can be used again at some point in the future as either the production site or standby site, if desired.

To use the original production site as the current standby site, you need to reestablish the rsync replications between the two sites, but configure the replications so that they go in the opposite direction (from the current production site to the current standby site).

To use the original production site as the new production site, you perform the steps above again, but configure the rsync replications to go in the original direction (from the original production site to the original standby site).