3 Active-Passive Application Tier with Active-Passive Database Tier
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.
Topics include:
- Active-Passive Topology Architecture Description
This MAA architecture consists of an active-passive application infrastructure tier with an active-passive database tier and in which both tiers span two geographically different sites. At the first site, both the application infrastructure tier and the database tier are active. At the second site, the secondary domain is shutdown, and the secondary database is on standby. - Active-Passive Topology Design Considerations
Consider Oracle’s best practice design recommendations for continuous availability in an active-passive application tier topology with an active-passive database tier.
Active-Passive Topology Architecture Description
This MAA architecture consists of an active-passive application infrastructure tier with an active-passive database tier and in which both tiers span two geographically different sites. At the first site, both the application infrastructure tier and the database tier are active. At the second site, the secondary domain is shutdown, and the secondary database is on standby.
Figure 3-1 shows a recommended architecture using an active-passive application infrastructure tier with an active-passive database tier.
Figure 3-1 Active-Passive Application Tier with Active-Passive Database Tier Architecture Diagram
Description of "Figure 3-1 Active-Passive Application Tier with Active-Passive Database Tier Architecture Diagram"
The key aspects of this topology include:
-
A global load balancer.
-
Two active instances of Oracle HTTP Server (OHS) on Site 1 and two passive instances of OHS on Site 2. OHS can balance requests to the WebLogic Server cluster.
-
Two separate WebLogic Server domains configured in two different data centers, Site 1 and Site 2. The domain at Site 1 is active and the secondary domain at Site 2 is shutdown. The configuration of each active-passive domain must be identical. See Active-Passive Topology Design Considerations.
The domains include:
-
A collection of Managed Servers (MS1, MS2, and MS3) in a WebLogic Server cluster, managed by the WebLogic Server Administration Server in the domain. In this sample, Active Gridlink (AGL) is being used to connect the Managed Servers to the primary database. (Although a generic data source or multi data source can be used, Active Gridlink is preferable because it offers high availability and improved performance).
The Zero Downtime Patching (ZDT) arrows represent patching the Managed Servers in a rolling fashion. In this architecture, you can use the Zero Downtime Patching feature on the active domain in Site 1 as described in WebLogic Server Zero Downtime Patching. Because the servers are not running in the secondary domain at Site 2, you can use OPatch to patch the Oracle home. When the servers become active, they will point to the patched Oracle home. See Patching Your Environment Using OPatch in Patching with OPatch.
-
A Coherence cluster (COH1, COH2, and COH3) managed by the WebLogic Server Administration Server in the domain. Coherence persistent caching is used to recover cached data in case of a failure in the Coherence cluster. Read-Through caching or Coherence GoldenGate Hot Cache is used to update cache from the database.
Using Coherence Hot Cache in this architecture, updates on the active database at Site 1 update the Coherence cache in real time and the database updates are replicated to Site 2. When the data replication occurs on Site 2, HotCache updates the cache in real time. See Coherence GoldenGate HotCache.
Coherence Federated Caching replicates data from the active cluster to the passive cluster. The passive site supports read-only operations and off-site backup. See Coherence Federated Caching.
-
-
A file storage for the configuration data, local binaries, logs, and so on.
-
Two separate Oracle RAC database clusters in two different data centers. The primary active Oracle RAC database cluster is at Site 1. Site 2 contains an Oracle RAC database cluster in standby (passive) read-only mode. The clusters can contain transaction logs, JMS stores, and application data. Data is replicated using Oracle Active Data Guard. (Although Oracle recommends using Oracle RAC database clusters because they provide the best level of high availability, they are not required. A single database or multitenant database can also be used.)
-
The secondary WebLogic domain configuration is a replica of the primary domain. A replication technology (storage level replication, rsync, DBFS) is used to copy the middle-tier file systems and other data from the production site's storage to the standby site's storage.
Active-Passive Topology Design Considerations
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.
-
The passive site must contain an exact copy of the WebLogic domain config of the primary site. A replication technology (storage level replication, rsync, DBFS) is used to copy the middle tier file systems and other data from the production site's storage to the standby site's storage.
After storage replication is enabled, application deployment, configuration, metadata, data, and product binary information are replicated from the production site to the standby site.
-
JMS is supported in this topology. Using database stores for JMS is recommended, because high availability and cross-site replication is automatically provided by the underlying Oracle RAC database and Data Guard.
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), hence using database-based stores is recommended to take advantage of the underlying Data Guard replication.
See Recommendations for Oracle WebLogic Server Java Message Service (JMS) and Transaction Logs (T-Logs) 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.