2 Supported MAA Architectures for Continuous Availability
The supported MAA solutions include:
Active-Active Application Tier with an Active-Passive Database Tier
Figure 2-1 shows a recommended continuous availability solution using an active-active application infrastructure tier with an active-passive database tier. For design considerations and best practices, see Design Considerations for Active-Active Application Tier Topology.
Figure 2-1 Topology for an Active-Active Application infrastructure Tier with an Active-Passive Database Tier
Description of "Figure 2-1 Topology for an Active-Active Application infrastructure Tier with an Active-Passive Database Tier"
The key aspects of this sample topology include:
-
A global load balancer.
-
Two instances of Oracle Traffic Director (OTD) at each site, one active and one passive. Oracle Traffic Director can balance requests to the web tier or to the WebLogic Server cluster.
-
Oracle HTTP Server (OHS) Web Tier (optional component based on the type of environment).
-
Two separate WebLogic Server domains configured in two different data centers, Site 1 and Site 2. The domains at both sites are active and must be configured with symmetric topology. See Active-Active Application Tier With Active-Passive Database Tier 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 (AG) is being used to connect the Managed Servers to the primary database. (Although generic DataSource or MultiDataSource 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.
-
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 cache is used to update cache from the database.
-
-
A file store for the configuration data, local binaries, logs, and so on.
-
Oracle Site Guard, a component of Oracle Enterprise Manager Cloud Control, that orchestrates the failover and switchover of sites.
-
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.)
This topology uses the continuous availability features as follows:
-
Automated cross-site XA transaction recovery: Because both domains are active, you can use the full capabilities of this feature, as described in Automated Cross-Site XA Transaction Recovery. In this architecture, transactions can be recovered automatically, without any manual intervention.
-
WebLogic Zero Downtime Patching: Because both domains are active, you can orchestrate the roll out of updates separately on each site. See WebLogic Server Zero Downtime Patching.
-
Coherence federated caching: You can use the full capabilities of this feature, as described in Coherence Federated Caching. Cached data is replicated between clusters. Applications in different sites have access to a local cluster instance.
-
Coherence HotCache: Updates the Coherence cache in real time for any updates that are made on the active database. See Coherence GoldenGate HotCache.
-
Oracle Traffic Director: Adjusts traffic routing to application servers depending on server availability. You can achieve high availability with Oracle Traffic Director by having a pair of instances configured at each site, either active-active or active-passive. See Oracle Traffic Director.
-
Oracle Site Guard: Because only the database is in standby mode in this architecture, Oracle Site Guard controls database failover only. It does not apply to the application architecture tier because both domains are active. See Oracle Site Guard.
Active-Passive Application Tier with an Active-Passive Database Tier
Figure 2-2 shows a recommended continuous availability topology using an active-passive application infrastructure tier with an active-passive database tier. For design considerations and best practices, see Active-Passive Application Tier with an Active-Passive Database Tier.
Figure 2-2 Topology for an Active-Passive Application infrastructure Tier with an Active-Passive Database Tier
Description of "Figure 2-2 Topology for an Active-Passive Application infrastructure Tier with an Active-Passive Database Tier"
The key aspects of this topology include:
-
A global load balancer.
-
Two instances of Oracle Traffic Director (OTD) at each site. Oracle Traffic Director can balance requests to the web tier or to the WebLogic Server cluster. At Site 1, one instance is active and one is passive. On Site 2 they are both on standby. When Site 2 becomes active, the Oracle Traffic Director instances on that site will start routing the requests.
-
Oracle HTTP Server (OHS) Web Tier (optional component based on the type of environment).
-
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 domain at Site 2 is in standby (passive) mode. The configuration of each active-passive domain pair must be identical. See Active-Passive Application Tier With Active-Passive Database Tier 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 (AG) is being used to connect the Managed Servers to the primary database. (Although generic DataSource or MultiDataSource 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.
-
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 cache is used to update cache from the database.
-
-
A file store for the configuration data, local binaries, logs, and so on.
-
Oracle Site Guard, a component of Oracle Enterprise Manager Cloud Control, that orchestrates the failover and switchover of sites.
-
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.)
This architecture uses the continuous availability features as follows:
-
Automated cross-site XA transaction recovery: Because the domain at Site 2 is in standby mode, during failover, you must first start the domain at Site 2. After you start the domain, you can use the cross-site XA transaction recovery features, as described in Automated Cross-Site XA Transaction Recovery.
-
WebLogic Server Zero Downtime Patching: 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 standby (passive) domain at Site 2, you can use OPatch. When the servers become active, they will point to the patched Oracle home. See Patching Your Environment Using OPatch in Patching with OPatch
-
Coherence federated caching: In this architecture, the passive site supports read-only operations and off-site backup. See Coherence Federated Caching.
-
Coherence HotCache: 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.
-
Oracle Traffic Director: In this architecture, Oracle Traffic Director is in standby mode on the standby (passive) domain at Site 2. When Site 2 becomes active after failover, the Oracle Traffic Director instance on the standby site is activated (by Oracle Site Guard using a script that is run before or after failover) and the Oracle Traffic Director instance will start routing requests to the recently started servers. See Oracle Traffic Director.
-
Oracle Site Guard: In this architecture, when Site1 fails, Oracle Site Guard will initiate the failover using scripts that specify what should occur and in what order. For example, it can start WebLogic Server, Coherence, web applications, and other site components in a specific order. You can execute the scripts either pre- or post-failover. Oracle Site Guard integrates with Oracle Data Guard broker to fail over the database. See Oracle Site Guard.
Active-Active Stretch Cluster with an Active-Passive Database Tier
Figure 2-3 shows a recommended continuous availability solution using an active-active stretch cluster application infrastructure tier with an active-passive database tier. For design considerations and best practices, see Active-Active Stretch Cluster with an Active-Passive Database Tier.
Figure 2-3 Topology for an Active-Active Stretch Cluster Application Infrastructure Tier and an Active-Passive Database Tier
Description of "Figure 2-3 Topology for an Active-Active Stretch Cluster Application Infrastructure Tier and an Active-Passive Database Tier"
The key aspects of this topology include:
-
A global load balancer.
-
Two instances of Oracle Traffic Director (OTD) at each site, one active and one passive. Oracle Traffic Director can balance requests to the web tier or to the WebLogic Server cluster.
-
Oracle HTTP Server (OHS) Web Tier (optional component based on the type of environment).
-
WebLogic Server configured as a cluster that stretches across two different data centers, Site 1 and Site 2. All servers in the cluster are active. The cluster can be either dynamic or static. See Clustering.
-
The domain includes:
-
A WebLogic Server cluster that consists of a group of Managed Servers (MS1, MS2, and MS3) at Site 1 and another group of Managed Servers (MS4, MS5, and MS6) at Site 2. The Managed Servers are managed by the WebLogic Server Administration Server at Site 1. In this sample, Active Gridlink (AG) is being used to connect the Managed Servers to the primary database. (Although generic DataSource or MultiDataSource 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.
-
A Coherence cluster at each site (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 cache is used to update cache from the database.
-
-
A file store for the configuration data, local binaries, logs, and so on.
-
Oracle Site Guard, a component of Oracle Enterprise Manager Cloud Control, that orchestrates the failover and switchover of sites.
-
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.)
This architecture uses the continuous availability features as follows:
-
Automated cross-site XA transaction recovery: Because all of the servers are in the same cluster, you can use the existing WebLogic Server high availability features, server and service migration, to recover transactions.
-
In whole server migration, a migratable server instance, and all of its services, is migrated to a different physical machine upon failure. See Whole Server Migration in Administering Clusters for Oracle WebLogic Server.
-
In service migration, in the event of failure, services are moved to a different server instance within the cluster. See Service Migration in Administering Clusters for Oracle WebLogic Server.
-
-
WebLogic Zero Downtime Patching: Because all of the servers in the cluster are active, you can use the full capabilities of this feature as described in WebLogic Server Zero Downtime Patching.
-
Coherence federated caching: You can use the full capabilities of this feature, as described in Coherence Federated Caching.
-
Coherence HotCache: You can use the full capabilities of this feature, as described in Coherence GoldenGate HotCache.
-
Oracle Traffic Director: Adjusts traffic routing to application servers depending on server availability. You can use the full capabilities of this feature, as described in Oracle Traffic Director.
-
Oracle Site Guard: Because only the database is in standby mode in this architecture, Oracle Site Guard controls database failover only. It does not apply to the application architecture tier because all servers in the cluster are active. See Oracle Site Guard.