Oracle Adaptive Access Manager High Availability Architecture

Configuring High Availability for Identity Management Components 8-211 properties can be changed using the Oracle Adaptive Access Manager Administration Console. Oracle Adaptive Access Manager does not store any configuration information on the file system or in the exploded EAR file.

8.12.1.1.5 Oracle Adaptive Access Manager Deployment Artifacts Oracle Adaptive Access

Manager supports the nostage mode of deployment staging. That is, all deployment files are local.

8.12.1.1.6 Oracle Adaptive Access Manager External Dependencies Oracle Adaptive Access

Manager has an external dependency on the RDBMS database, where it stores its configuration information. Oracle Adaptive Access Manager uses WebLogic Server multi data sources for Oracle RAC databases. Oracle Adaptive Access Manager uses the standard Oracle TopLink object caching mechanism. Oracle Adaptive Access Manager follows standard session object serialization to maintain the persistent state of an object. Oracle Adaptive Access Manager is not dependent on any hostname, IP address, or port. It will work on a container-specific port or host name.

8.12.1.1.7 Oracle Adaptive Access Manager Log File Location Oracle Adaptive Access

Manager is a J2EE application deployed on WebLogic Server. All log messages are logged in the server log file of the WebLogic Server that the application is deployed on. The default location of the server log is: WL_HOME user_projectsdomainsdomainNameserversserverNamelogs serverName -diagnostic.log

8.12.2 Oracle Adaptive Access Manager High Availability Concepts

This section provides conceptual information about using Oracle Adaptive Access Manager in a high availability two-node cluster.

8.12.2.1 Oracle Adaptive Access Manager High Availability Architecture

Figure 8–19 shows the Oracle Adaptive Access Manager high availability architecture: 8-212 Oracle Fusion Middleware High Availability Guide Figure 8–19 Oracle Adaptive Access Manager High Availability Architecture In Figure 8–19 , incoming requests are received by the hardware load balancer, which routes them to WEBHOST1 or WEBHOST2 in the web tier. These hosts have Oracle HTTP Server installed. The Oracle HTTP Server then forwards requests on to the WebLogic managed servers on OAAMHOST1 and OAAMHOST2 using the WebLogic plugin mod_wl_ohs. OAAMHOST1 and OAAMHOST2 contain managed servers which host the Oracle Adaptive Access Manager Server application and the Oracle Adaptive Access Manager Admin application. These managed servers are configured in a cluster which allows the Access Servers to work in an active-active manner. The WebLogic Administration Server runs on OAAMHOST1 and contains the WebLogic Administration Console and the Oracle Enterprise Manager Fusion Middleware Control. The Administration Server can be configured to run in active-passive mode on OAAMHOST2, which means that if OAAMHOST1 becomes unavailable, then Administration Server can be manually started on OAAMHOST2. OAAMHOST2 OAAMHOST1 RAC Database Admin Server OAAM_CLUSTER WLS_OAAM1 TopLink TopLink OAAM_SERVER WEBHOST2 WEBHOST1 OHS OHS WLS_OAAM2 mod_wl_ohs mod_wl_ohs Admin Server OAAM_SERVER OAAM_ADMIN_CLUSTER WLS_OAAM_ADMIN1 OAAM_ADMIN WLS_OAAM_ADMIN2 OAAM_ADMIN Load Balancer HTTP Firewall HTTP Configuring High Availability for Identity Management Components 8-213 In the directory tier, the virtual IP ovd.mycompany.com is set up to route Oracle Virtual Directory requests to OVDHOST1 and OVDHOST2, which comprise an active-active Oracle Virtual Directory cluster. The virtual IP oid.mycompany.com is set up to route Oracle Internet Directory requests to OIDHOST1 and OIDHOST2, which comprise an active-active Oracle Internet Directory cluster. An Oracle RAC database provides high availability in the data tier. Figure 8–19 shows the OAAM high availability configuration architecture. In the figure, a load balancer routes requests through two Oracle HTTP Server instances on WEBHOST1 and WEBHOST2 to OAAMHOST1 and OAAMHOST2. An OAAM Administration Server instance and an OAAM Managed Server instance is installed on OAAMHOST1 and on OAAMHOST2, and these installations are configured as an OAAM Server cluster OAAM_Cluster and an OAAM Admin Cluster OAAM_ Admin_Cluster. The OAAM Server cluster uses the OAAM Server data source and the OAAM Admin cluster uses the OAAM Admin data source to communicate with the Oracle RAC database. As shown in Figure 8–19 , only one Oracle Adaptive Access Manager Server cluster and one Oracle Adaptive Access Manager Administration cluster is supported per WebLogic Server domain. In addition, Oracle Adaptive Access Manager-related clusters cannot span WebLogic Server domains. A single instance Oracle Adaptive Access Manager deployment satisfies the following high availability requirements: ■ Load handling ■ External connection management and monitoring ■ Recovery ■ Fault containment ■ Fault diagnostics ■ Oracle Adaptive Access Manager Admin Server offline A multiple instance Oracle Adaptive Access Manager deployment satisfies the following additional high availability requirements: ■ Redundancy ■ Client connection failover continuity ■ Client load balancing ■ State management Use of external load balancing routers is recommended for inbound HTTP connections. Web sessions open persistent TCP connections to the Oracle Adaptive Access Manager Administration Console and servers. This requires that load balancing router and firewall connection timeouts are sufficiently large to avoid premature termination of TCP connections.

8.12.2.1.1 Starting and Stopping the Cluster Each Oracle Adaptive Access Manager

Administration Console and Server instance is a peer of other instances. Because all initialization happens before the Server is ready to receive requests and because of built in throttling capabilities, surge conditions are dealt with gracefully without any significant impact of the performance characteristics of the Oracle Adaptive Access Manager 11gR1 Access Server. 8-214 Oracle Fusion Middleware High Availability Guide When the cluster is stopped, new requests will be denied and existing requests will be allowed to complete before the Oracle Adaptive Access Manager Administration Console and Server application shuts down. If a forced shutdown occurs, Oracle Adaptive Access Manager 11gR1 can recover any corrupted or invalid data that the shutdown causes. Oracle Adaptive Access Manager components are pure J2EE applications and do not have any start or stop functionality of their own. Instead, they rely on container-specific startup and shutdown functionality. Oracle Adaptive Access Manager components are deployed to WebLogic Server Managed Server nodes. The components can be restarted using Node Manager.

8.12.2.1.2 Cluster-Wide Configuration Changes Since Oracle Adaptive Access Manager

stores the entire configuration in database, the propagation of configuration changes to all the cluster members transparent. All Oracle Adaptive Access Manager components are notified of change events from the internal layer, which are then taken up by the components. To ensure atomicity of the change, Oracle Adaptive Access Manager components reload their entire configuration every time a change happens. Oracle Adaptive Access Manager configuration applies to every instance in a cluster. Adding and removing Oracle Adaptive Access Manager Administration Console and Server instances is transparent to other Oracle Adaptive Access Manager instances in the cluster. An Oracle Adaptive Access Manager cluster can have any number of instances. There is no restriction on the number of instances per cluster. Online application redeployment does not cause any problems.

8.12.2.2 Protection from Failures and Expected Behaviors