Setting Up and Managing Disaster Recovery Sites 4-67
The Oracle SOA Suite asymmetric standby site shown in Figure 4–13
has fewer hosts and instances than the Oracle SOA Suite production site shown in
Figure 4–2 .
The hosts WEBHOST2 and SOAHOST2 and the instances on those hosts exist at the production site in
Figure 4–2 , but these hosts and their instances do not exist at the
asymmetric standby site in Figure 4–13
. The standby site therefore has fewer hosts and fewer instances than the production site.
It is important to ensure that this asymmetric standby site will have sufficient resources to provide adequate performance when it assumes the production role.
When you follow the steps in Section 4.4.1, Creating the Asymmetric Standby Site
to set up this asymmetric standby site, the standby site should be properly configured to
assume the production role. To set up the asymmetric standby site correctly, create the same volumes and
consistency groups on the standby site shared storage as you did on the production site shared storage. For example, for the Oracle SOA Suite deployment, the volume
design recommendations in Table 4-4 and the consistency group recommendations in Table 4-5 were used to set up the production site shared storage. You will use these
same volume design recommendations and consistency group recommendations that you used for the production site shared storage to set up the asymmetric standby site’s
shared storage.
Note that at an asymmetric standby site, some hosts that exist at the production site do not exist at the standby site. For example, in the case of the asymmetric standby site for
Oracle SOA Suite shown in Figure 4–13
, WEBHOST2 and SOAHOST2 do not exist at the standby site, therefore it is not possible or necessary for you to create mount points
on these hosts to the standby site shared storage volumes.
4.4.2 Validating the Asymmetric Standby Site Setup
Validate the standby site by following the steps below:
1.
Shut down any processes still running on the production site. This includes the database instances in the data tier, Oracle Fusion Middleware instances and any
other processes in the application tier and web tier.
2.
Stop the replication between the production site shared storage and the standby site shared storage.
3.
Use Oracle Data Guard to fail over the databases.
4.
On the standby site hots, manually start all the processes. This includes the database instances in the data tier, Oracle Fusion Middleware instances and any
other processes in the application tier and web tier.
5.
Use a browser client to perform post-failover testing to confirm that requests are being resolved and redirected to the standby site.
4.5 Performing Site Operations and Administration
This section describes operations and administration to perform on your Oracle Fusion Middleware Disaster Recovery topology.
4.5.1 Synchronizing the Sites
The standby site shared storage receives snapshots transferred on a periodic basis from the production site shared storage. After the snapshots are applied, the standby
site shared storage will include all the data up to and including the data contained in
4-68 Oracle Fusion Middleware Disaster Recovery Guide
the last snapshot transferred from the production site before the failover or switchover.
You should manually force a synchronization operation whenever a change is made to the middle tier at the production site for example, when a new application is
deployed at the production site. Follow the vendor-specific instructions for forcing a synchronization using storage replication technology.
The synchronization of the databases in the Oracle Fusion Middleware Disaster Recovery topology is managed by Oracle Data Guard.
4.5.2 Performing a Switchover
When you plan to take down the production site for example, to perform maintenance and make the current standby site the new production site, you must
perform a switchover operation so that the standby site takes over the production role.
Follow these steps to perform a switchover operation:
1.
Shut down any processes still running on the production site. This includes the database instances in the data tier, Oracle Fusion Middleware instances and any
other processes in the application tier and web tier.
2.
Stop the replication between the production site shared storage and the standby site shared storage.
3.
Use Oracle Data Guard to switch over the databases.
4.
On the standby site hots, manually start all the processes. This includes the database instances in the data tier, Oracle Fusion Middleware instances and any
other processes in the application tier and web tier.
5.
Ensure that all user requests are routed to the standby site by performing a global DNS push or something similar, such as updating the global load balancer.
6.
Use a browser client to perform post-switchover testing to confirm that requests are being resolved and redirected to the standby site.
At this point, the former standby site is the new production site and the former production site is the new standby site.
7.
Reestablish the replication between the two sites, but configure the replication so that the snapshot copies go in the opposite direction from the current production
site to the current standby site. Refer to the documentation for your shared storage to learn how to configure the replication so that snapshot copies are
transferred in the opposite direction.
After these steps have been performed, the former standby site is the new production site. At this point, you can perform maintenance at the original production site. After
performing the planned tasks on the original production site, you can use it again at some point in the future as either the production site or standby site.
To use the original production site as the new production site, perform the switchback steps described in
Section 4.5.3, Performing a Switchback.
