In an active-passive application tier topology, an active site is paired with a passive site that is on standby at a geographically different location. When designing an active-passive solution, consider Oracle’s best practices.
In addition to the general best practices recommended for all continuous availability MAA architectures as described in Common Design Considerations for Continuous Availability, the following sections describe the design considerations and failure scenarios that apply to the MAA architecture shown in Active-Passive Application Tier with an Active-Passive Database Tier.
Consider Oracle’s best practice design recommendations for continuous availability in an active-passive application tier topology with an active-passive database tier.
To take full advantage of continuous availability features in an active-passive topology, consider the following:
All active-passive domain pairs must be configured with symmetric topology; they must be identical and use the same domain configurations such as directory names and paths, port numbers, user accounts, load balancers and virtual server names, and software versions. Host names (not static IPs) must be used to specify the listen address of the Managed Servers. When hostnames between sites are identical (IPs are not), the hostname provides the dynamic ability to start an identically configured server or domain on the recovery site.
There are no latency considerations in this topology. The only requirement is that stores such as JMS and JTA TLogs are kept in the database.
In passive mode, WebLogic Server servers are configured but not running. When there is a failure, the WebLogic Server servers in the passive site are brought up and JTA and JMS transactions/messages are recovered. Work then takes place in the second site.
JMS is supported in this topology. The passive site should contain an exact copy of the domain on the primary site to ensure that the configuration of the JMS servers, stores, and destinations are the same.
In the case of a failover or switchover, if the store and/or JMS server is targeted at the cluster, you must start the same number of servers in the cluster. This process is required because each JMS server + store + destination is specific to the server on which it was running. If you have MyServer1 and MyServer2 in the primary domain, there is a JMS Server + store on each of those servers. It is possible that the queues on those servers contain messages. If you restart only one server, you only recover the messages for that one server.
The standby domain cannot be running during the replication phase, and started only after the initial data center is confirmed as down. This process is necessary to prevent data corruption and to force recovery. If two JMS server/stores are writing/updating the same exact data, unexpected results occur. Also, message recovery only happens on JMS server startup. Then, the JMS server reads the full store contents and recreates destination state.
Asynchronous replication can result in lost messages (message was written in the primary datacenter but not copied) or duplicate messages (message was consumed/deleted in the primary data center, but remains in the replicated data center).
See Recommendations for Oracle WebLogic Server Java Message Service (JMS) and Transaction Logs (TLogs) in Disaster Recovery Guide.
Zero Downtime Patching upgrades your WebLogic homes, Java, and applications in a rolling fashion in the active site. During a planned maintenance and switchover to the passive site and after servers have been started, use Zero Downtime Patching to upgrade WebLogic, Java, or applications. To keep the domains symmetric at both sites, keep upgrade versions on both sites in sync.
In the active-passive topology, Coherence is in Standby mode, not passive mode like WebLogic Server. The standby site has a backup of the cache data from the active site. With Coherence Federated Cache in active-passive mode, this replication happens asynchronously but it happens constantly.
In this topology Oracle recommends using Oracle Site Guard to orchestrate the failover/switchover of all site components: Oracle Traffic Director, WebTier, WebLogic Server, Coherence, and the database.
Learn how the Continuous Availability features are used in each of the different failure scenarios for an active-passive application tier topology.
Table 5-1 describes the different failure scenarios and how each Continuous Availability feature applies. For an explanation of the different failure scenarios, see Potential Failure Scenarios.
Table 5-1 Active-Passive Application Tier and Active/Passive Database Tier Failure Scenarios
| Continuous Availability Features | Complete Site Failure | Partial Site/Mid-Tier Failure (WebLogic Server/Coherence/OTD) | Maintenance Outage | Network Partition Failure |
|---|---|---|---|---|
|
Transaction Recovery Across Sites |
|
|
|
No-op. |
|
Oracle Traffic Director |
Oracle Traffic Director instance on the standby site is activated (by Oracle Site Guard using a failover script that specifies what should occur and in what order. The script can be run before or after failover). |
|
Oracle Traffic Director instance on the standby site is activated (by Oracle Site Guard using a failover script that specifies what should occur and in what order. The script can be run before or after failover). |
No-op. |
|
Oracle Site Guard |
Oracle Site Guard integrates with Oracle Data Guard broker to perform database failover/switchover. Site Guard calls Oracle Data Guard broker to perform the failover and Site Guard switches the roles from primary to secondary. |
Oracle Site Guard fails over only the mid-tier. |
|
No-op. |
|
Coherence Federated Caching |
Coherence cluster on Site 2 becomes active. The cache data eventually becomes consistent either through Coherence Hot Cache or Read-Through cache. |
Coherence cluster on Site 2 becomes active. The cache data eventually becomes consistent either through Coherence Hot Cache or Read-Through cache, or when the remote site comes back up. |
Coherence cluster on Site 2 becomes active. The cache data eventually becomes consistent either through Coherence Hot Cache or Read-Through cache, or when the remote site is brought back up. |
Cache data eventually becomes consistent either through Coherence Hot Cache or Read-Through cache, or when the network connectivity is re-established between the two sites. |