Oracle Access Manager High Availability Architecture

8-118 Oracle Fusion Middleware High Availability Guide

8.8.2 Oracle Access Manager High Availability Concepts

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

8.8.2.1 Oracle Access Manager High Availability Architecture

Figure 8–13 shows an Oracle Access Manager high availability architecture: Configuring High Availability for Identity Management Components 8-119 Figure 8–13 Oracle Access Manager High Availability Architecture In Figure 8–13 , incoming authentication requests are received by the hardware load balancer, which routes them to WEBHOST1 or WEBHOST2 in the web tier. These hosts OAMHOST2 OAMHOST1 RAC Database WLS_OAM1 Access Server WEBHOST2 WEBHOST1 OHS OHS WLS_OAM2 mod_wl_ohs OVDHOST1 OVD OVD_INST1 OVDHOST2 OVD OVD_INST2 OIDHOST1 OVD OID_INST1 OIDHOST2 OVD OID_INST2 mod_wl_ohs Access Server Coherence DOC VIP: ovd.mycompany.com VIP: oid.mycompany.com WLS Admin Server OAM Console Admin Console WLS Admin Server OAM Console Admin Console Load Balancer HTTP Firewall Firewall HTTP WEBHOST3 OHS mod_wl_ohs WebGate OAP 8-120 Oracle Fusion Middleware High Availability Guide have Oracle HTTP Server installed. The Oracle HTTP Server then forwards requests on to the WebLogic managed servers using the WebLogic plugin mod_wl_ohs. The load balancing router should use session stickiness for HTTP traffic only. OAP traffic does not use a load balancing router, so session stickiness is not required for OAP traffic. Applications which are accessed by other Oracle HTTP Servers whose resources have restricted access must also have a WebGate, Oracle Single Sign-On Server agent mod_ osso agent, or custom agent configured. The WebGate on WEBHOST3 communicates with the Access Servers on OAMHOST1 and OAMHOST2 in the application tier using OAP. WEBHOST3 is an application web server, and for authentication, HTTP redirect is used to route requests to the load balancer and to WEBHOST1 and WEBHOST2. For a high availability deployment, you can optionally configure another host for example, WEBHOST4 with the same components as WEBHOST3. OAMHOST1 and OAMHOST2 deploy managed servers which host the Oracle Access Server 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 OAMHOST1 and deploys the WebLogic Administration Console, Oracle Enterprise Manager Fusion Middleware Control, and the Oracle Access Manager Console. The Administration Server can be configured to run in active-passive mode on OAMHOST2, which means that if OAMHOST1 becomes unavailable, then Administration Server can be manually started on OAMHOST2. 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. In Oracle Access Manager 11gR1, only one Oracle Access Manager cluster is supported per WebLogic Server domain. In addition, Oracle Access Manager clusters cannot span WebLogic Server domains. A single instance Oracle Access Manager 11gR1 deployment satisfies the following high availability requirements: ■ Load handling ■ External connection management and monitoring ■ Recovery ■ Fault containment ■ Fault diagnostics ■ Administration Server offline A multiple instance Oracle Access Manager 11gR1 deployment satisfies the following additional high availability requirements: ■ Redundancy ■ Client connection failovercontinuity ■ Client load balancing ■ State management Configuring High Availability for Identity Management Components 8-121 Use of an external load balancing router is recommended for inbound HTTP connections. Outbound external connections to LDAP Servers or OAM policy engine PDPPIP are load balanced with support for connection failover. Oracle Access Manager agents can load balance connections across multiple Access Servers. Oracle Access Manager agents open persistent TCP connections to the Access Servers. This requires firewall connection timeouts to be sufficiently large to avoid premature termination of TCP connections. The Access Server and Oracle Access Manager Administration Console interface with the OAM policy engine for policy evaluation and management. The OAM policy engine internally depends on a database as the policy repository. The database interactions are encapsulated within the OAM policy engine, with only the connectivity configuration information managed by Oracle Access Manager. The high availability characteristics of the interaction between Oracle Access Manager and the OAM policy engine are: ■ The database connection information is configured in the Oracle Access Manager configuration file synchronized among the Oracle Access Manager instances. Should the database connection information change at runtime, Access Server instances will re-initialize OES to complete the change activation. ■ Database communication is managed within the OAM policy engine, and generally decoupled from Oracle Access Manager and OAM policy engine interactions. The very first startup of an Oracle Access Manager server instance will fail, however, if the database is unreachable. An OAM policy engine bootstrap failure is treated as fatal by Oracle Access Manager, and the startup operation is aborted. ■ Transient database unavailability is transparently tolerated by OAM policy engine policy evaluation services, allowing Oracle Access Manager server runtimes to continue functioning uninterrupted. After the initial OAM policy engine bootstrap, the Oracle Access Manager instances may even be restarted while the database is unreachable -- the OAM policy engine will continue operating against its locally cached policies. ■ Oracle Access Manager policy management interfaces in the Oracle Access Manager Administration Console and the CLI tool will fail if the database is unreachable, as seen by the OAM policy engine management service interfaces. The operation may be retried at a later point in time, but no automated retry is provided for management operations. ■ Following a successful policy modification in the database repository, the OAM policy engine layer in the Oracle Access Manager server runtimes retrieves and activates the changes within a configurable OAM policy engine database poll interval configured through Oracle Access Manager configuration. A positive acknowledgement of a policy change must be received from each Oracle Access Manager server runtime, otherwise the policy change cannot be considered successfully activated. The administrator can use the Oracle Access Manager Administration Console to remove any Oracle Access Manager instance with a policy activation failure from service.

8.8.2.1.1 Starting and Stopping the Cluster In a high availability architecture, Oracle

Access Manager server is deployed on an Oracle WebLogic Cluster, which has at least two servers as a part of the cluster. By default, Oracle WebLogic Server starts stops, monitors and manages the various lifecycle events for the application. The Oracle Access Manager application leverages the high availability features of the underlying Oracle WebLogic Clusters. In case of 8-122 Oracle Fusion Middleware High Availability Guide hardware or other failures, session state is available to other cluster nodes that can resume the work of the failed node. In a high availability environment, WebLogic Node Manager is configured to monitor the Oracle WebLogic Servers. In case of failure, Node Manager restarts the WebLogic Server. In a high availability environment, a hardware load balancer is used to load balance requests between the multiple Oracle Access Manager instances. If one of the Oracle Access Manager instances fails, the load balancer detects the failure and routes requests to the surviving instances.

8.8.2.1.2 Cluster-Wide Configuration Changes The standard Java EE artifacts that Oracle

Access Manager uses are configured as part of the Oracle WebLogic domain in which Oracle Access Manager is installed. Oracle WebLogic Clusters provide automatic configuration synchronization for artifacts, such as data sources, across the WebLogic Server domain. At the same time, the WebLogic Server cluster synchronizes the deployments and libraries used by the Oracle Access Manager components. Additionally, Oracle Access Manager application level configuration is stored in the Oracle Access Manager repository. Propagation of Oracle Access Manager configuration changes to all the cluster members is based on a distribution mechanism that leverages the Coherence Distributed Object Cache. All Oracle Access Manager components are notified of change events from the coherence layer, which are then taken up by the components. To ensure atomicity of the change, Oracle Access Manager components reload their entire configuration every time a change happens. Oracle Access Manager configuration applies to all instances in a cluster. The only exceptions to the above instance-specific configuration supported in Oracle Access Manager 11gR1 are the Oracle Access Manager proxy host, Oracle Access Manager proxy port, and the instance-specific Coherence configuration when Well Known Addresses WKA is used. The IP address of the proxy host and proxy port are stored in a configuration file. The Oracle Access Manager proxy port is the endpoint for OAP requests from agents. The IP address of the Coherence WKA is also stored in a configuration file. The Coherence WKA is used to determine the Coherence nodes that are authorized to receive Oracle Access Manager-specific traffic. The oam-configuration.xml file is the configuration file that stores this configuration information. It is possible to configure clients of the Oracle Access Manager proxy to access the service using this virtuallogical IP. The Oracle Access Manager proxy can be deployed and its clients still able to access the service when the logical IP and the component instance is migrated to any other physically different machine configured similarly. Adding and removing Access Server instances is transparent to other Oracle Access Manager Access Server instances in the cluster. However, take care to ensure that the removal of a specific Access Server does not affect the load balancing and failover characteristics of the agents. Restarting an Oracle Access Manager Access Server has no impact on any other running components or members of the cluster. Online application redeployment does not cause any problems. Configuring High Availability for Identity Management Components 8-123

8.8.2.2 Protection from Failures and Expected Behaviors