Oracle Access Manager 11g R2: Advanced Administration 3 - 2

Oracle Access Manager 11g R2: Advanced Administration 3 - 3

Oracle Access Manager 11g R2: Advanced Administration 3 - 4

High Availability (HA) Goals

Oracle Access Manager controls access to enterprise resources. If Oracle Access Manager goes down, enterprise users have no access to business applications. Therefore, Oracle Access Manager is a critical infrastructure component that must be always available under most circumstances. One of the primary goals of HA deployments is to minimize down time. Depending on the amount of permissible down time, different strategies for providing HA are employed. For example, in some organizations, it might be acceptable for Oracle Access Manager to be down one day every three months, while in other organizations, it might be acceptable for Oracle Access Manager to be down only five minutes per year. User session continuity is another common goal of HA deployments. Without user session continuity, if the server to which a user authenticated goes down, the user's session no longer exists, and the user is required to re-authenticate in order to access resources protected by Oracle Access Manager. With user session continuity, sessions can survive the failure of an Oracle Access Manager server. If the Oracle Access Manager server fails, users can continue to use resources protected by Oracle Access Manager without reauthenticating.

Oracle Access Manager 11g R2: Advanced Administration 3 - 5

High Availability (HA) Goals (continued)

Data loss or corruption might occur if, for example, a hard drive fails. Deploying redundant servers can protect a deployment from data loss. Backup and recovery procedures can help you restore operations to their full capacity. Finally, the entire data center might fail due to a catastrophic event. For mission-critical deployments, strategies such as data streaming and standby hardware can be used to bring a deployment back into operation quickly. The scope of this lesson is to describe techniques you use to provide HA for Oracle Access Manager deployments. But keep in mind that planning for HA is rarely limited to providing HA for Oracle Access Manager alone; rather, for an entire ecosystem in which Oracle Access Manager is a part.

Oracle Access Manager 11g R2: Advanced Administration 3 - 6

Oracle Access Manager 11g R2: Advanced Administration 3 - 7

Potential Points of Failure in an Oracle Access Manager Deployment

The term single point of failure describes a deployment node which, if it fails, renders an entire deployment unavailable. The slide identifies single points of failure in an Oracle Access Manager deployment. Subsequent slides describe strategies to mitigate single points of failure. Web Tier A deployment's Web tier consists of agents: 10g WebGates, 11g WebGates, and OHS instances running the mod_osso module. These agents serve as policy decision points for Oracle Access Manager. An agent can be a single point of failure for an Oracle Access Manager deployment. Assume the following conditions are true: A user requests a resource protected by an agent. There is only a single agent deployed in an Oracle Access Manager deployment. The host on which the agent is deployed is down, or the process running OHS is down. In this scenario, the user's request fails.

Oracle Access Manager 11g R2: Advanced Administration 3 - 8

Potential Points of Failure in an Oracle Access Manager Deployment (continued)

Application Tier The WebLogic managed server instance running the Oracle Access Manager application resides on the application tier, serving as a policy decision point. A WebLogic managed server instance can be a single point of failure for an Oracle Access Manager deployment. Assume the following conditions are true: A user requests a resource protected by an agent. The agent attempts to communicate with the Oracle Access Manager server, by using the server's OAP or HTTP port. The host on which the server is deployed is down, or the process running the WebLogic managed server instance is down. In this scenario, the user's request fails. Data Tier Back-end databases accessed by Oracle Access Manager serverthe audit database, policy database, session database, and identity storecomprise the data tier. A database on the data tier can be a single point of failure for an Oracle Access Manager deployment. Assume the following conditions are true: A user requests a resource protected by an agent. The agent attempts to communicate with the Oracle Access Manager server, by using the server's OAP or HTTP port. Oracle Access Manager server receives the request, and attempts to retrieve the policy that defines the authentication scheme for the resource. The policy databases host is down, or the process running the database is down. In this scenario, the user's request fails. Other Considerations Availability of resources served by Web servers and application serversthe resources that Oracle Access Manager protectscan also be single points of failure for a resource request. Providing high availability for resources served by Web servers and application servers is beyond the scope of this course.

Oracle Access Manager 11g R2: Advanced Administration 3 - 9

Load Balancing on the Web Tier

To protect against failure of a server running an agent, deploy redundant agents on the Web tier, and deploy a load balancer to forward requests to the agent. The agents must be of the same type. For example, you could not have 10g and 11g WebGates deployed behind the same load balancer. You can use a hardware or software load balancer in this deployment. Hardware load balancersfor example, Cisco Local Director or F5 Networks BIG-IP provide speed, high reliability, and advanced features. Software load balancersfor example, the reverse proxy plug-in for Oracle HTTP Serverare less expensive and suitable under certain circumstances. By placing a load balancer in front of redundant agents, the load balancer can detect whether the agent is available and, if not, will route requests only to agents that are available.

Note: The slide shows a deployment with a single load balancer. To eliminate the load balancer as a single point of failure, deploy redundant load balancers. The slide also shows two redundant agents. Deploy as many agents as you need to satisfy reliability and scalability requirements.

Oracle Access Manager 11g R2: Advanced Administration 3 - 10

Load Balancing on the Web Tier (continued)

The F5 Networks BIG-IP LTM WebGate The F5 Networks BIG-IP LTM is a hardware load balancer with built-in WebGate support. By deploying the BIG-IP LTM on the Web tier of an Oracle Access Manager deployment, you can provide agent redundancy. Cookie Stickiness Oracle Access Manager does not require you to configure cookie stickiness on the load balancer. Requests can be handled on any of the redundant agent instances. You can configure cookie stickiness to take advantage of other features, such as Web caches. Sticky cookies are not required by Oracle Access Manager, but are recommended for optimal performance. Configuring Multiple Redundant Agents behind a Load Balancer You can configure multiple redundant agents that reside behind a load balancer without registering each agent instance. Instead, perform the following steps: 1. Install WebGate software on every instance deployed behind the load balancer. 2. Register a single agent with Oracle Access Manager. If you use the oamreg remote registration utility, be sure the agent URL in the input file specifies the host name and port number of the load balancer. 3. Copy the agent artifact files to the WebGate configuration directory on each agent instance.

Oracle Access Manager 11g R2: Advanced Administration 3 - 11

Clustering the Oracle Access Manager Server on the Application Tier

To protect against failure of an Oracle Access Manager server running on the application tier, deploy a cluster of WebLogic managed server instances, each running the OAM server and other required applications and libraries. WebLogic clustering ensures that requests are routed to an available instance. You can configure the front end of the cluster with a load balancer or a Web proxy server plug-in. The load balancer or Web proxy server can detect whether a server is available, and if not, will route requests only to servers that are available. It is not necessary to configure the front end for cookie stickiness. Requests to the Oracle Access Manager server can be satisfied by any instance running in the cluster. The deployment of redundant Oracle Access Manager servers across multiple WebLogic Server clusters or domains is not supported in Oracle Access Manager 11g Release 1. Note: The slide shows a deployment with two clustered Oracle Access Manager server instances. You can deploy as many servers as you need to satisfy reliability and scalability requirements.

Oracle Access Manager 11g R2: Advanced Administration 3 - 12

WebLogic Server Cluster

An Oracle WebLogic Server cluster consists of multiple Oracle WebLogic Server instances, running simultaneously and working together to provide increased scalability and reliability. A cluster appears to clients as one Oracle WebLogic Server instance. The server instances that constitute a cluster can run on one machine or on different machines. You can increase a clusters capacity either by adding server instances to the cluster on an existing machine, or by adding machines to the cluster to host the incremental server instances. Each server instance in a cluster must run the same version of Oracle WebLogic Server. A cluster is a group of Oracle WebLogic Servers that coordinate with one another to provide clients access to the services provided by the entire cluster. Each Oracle WebLogic Server cluster is managed by a single administration server. These services may be a superset of the services provided by a single Oracle WebLogic Server instance.

Oracle Access Manager 11g R2: Advanced Administration 3 - 13

WebLogic Server Cluster (continued)

A cluster can exist on one or more computers as long as there are multiple Oracle WebLogic Server instances that are executing. The cluster provides an encapsulated interface to the services of the cluster. The cluster appears as a single instance to clients, whether these clients are Web-based or Java-based. By replicating the services provided on a single Oracle WebLogic Server instance, an enterprise system achieves a fail-safe environment and a scalable one. High availability is achieved through the replication of services so that when one server fails, a second server can resume operation where the first left off. Scalability is achieved by balancing the load of incoming requests across the servers in the cluster. If there are four Oracle WebLogic Server instances in a cluster and four requests enter the cluster, scalability can be achieved by balancing the four requests evenly across the cluster instances. A cluster is part of a particular Oracle WebLogic Server domain. All server instances in a cluster must reside in the same domain; you cannot split a cluster over multiple domains. Cluster Configuration Guidelines Observe the following guidelines when configuring WebLogic Server clusters: A cluster cannot span domains. All servers in a cluster must also be in the same domain. All servers within a cluster must be at the same version level. Clustered servers can be on the same or different machines with the same or different operating systems. There can be multiple clusters in a domain. There can only be a single cluster of Oracle Access Manager servers per domain.

Oracle Access Manager 11g R2: Advanced Administration 3 - 14

Configuring a WebLogic Cluster of Oracle Access Manager Servers on Multiple Hosts

You typically configure a clustered, highly available Oracle Access Manager deployment on multiple hosts. Use the following procedure to configure Oracle Access Manager in a clustered configuration on multiple hosts. Installation and Configuration Install WebLogic Server on each host. All installations must use the same version of WebLogic Server software. It is not required that the hosts run the same operating system. Install Oracle Access Manager on each host. Then configure Oracle Access Manager on the host on which you want to deploy the domain's administration server. During the Customize Server and Cluster Configuration step, identify all the servers and the cluster on which Oracle Access Manager will run. On the host that runs the administration server, start the node manager and the administration server.

Oracle Access Manager 11g R2: Advanced Administration 3 - 15

Configuring a WebLogic Cluster of Oracle Access Manager Servers on Multiple Hosts (continued)
Domain Configuration Propagation Next, propagate the domain configuration from the first host to all other hosts on which managed server instances participating in the cluster reside. To propagate the domain configuration, use the pack.sh and unpack.sh utilities. Run the pack.sh utility on the first host to package the domain configuration, and unpack.sh on all other hosts to install the domain configuration. Start node managers on all the hosts to which you are propagating the domain configuration. Then start the other managed server instances running Oracle Access Manager by using the command line or the WebLogic console. Changing the Request Cache Type from the BASIC Type to the COOKIE Type Next, you can change the cookie request type from the BASIC type to the COOKIE type. This optional configuration change causes information normally maintained in the URL string during authentication to instead be maintained in the OAM_REQ cookie. You should make this change if your users' browsers enforce small size limits on the length of the URL string; this option enables you to decrease the URL size. Use the following WLST command to change the cache request type: configRequestCacheType(type="COOKIE") After changing the cache request type, you must restart all the managed server instances in the WebLogic cluster. Installing and Configuring the Load Balancer Next, you place a hardware load balancer, software load balancer, or Web proxy in front of managed server instances in the WebLogic cluster. The steps you follow depend on the type of load balancer you choose. You must configure the Oracle Access Manager server to be aware of the load balancer. In the console, change the host name and port number in the SSO engine configuration to the load balancer's host name and port. After changing the SSO engine host name and port number, you must restart all the managed server instances in the WebLogic cluster. Reconfiguring Agents Agents that previously communicated directly with the Oracle Access Manager server must be reconfigured to communicate with the load balancer. To reconfigure agents: Modify the agent configuration parameters to contain the cluster members' hosts and OAP port numbers. Note that agent HA is based on a primary/secondary failover model. Reregister the agent. Copy the agent artifacts to the agent configuration. Restart the agent.

Oracle Access Manager 11g R2: Advanced Administration 3 - 16

Converting a Single OAM Server on a Single Host to a Clustered Configuration

When working in a development environment with a single host, you might want to convert an environment with a single Oracle Access Manager server to a clustered environment with multiple managed server instances, each running Oracle Access Manager server. You use this technique in the practices for this lesson. Cluster Configuration Stop the managed server instance running Oracle Access Manager server. Use the WebLogic administration console to create a cluster and add the managed server instance running Oracle Access Manager server to the cluster.

Oracle Access Manager 11g R2: Advanced Administration 3 - 17

Converting a Single OAM Server to a Clustered Configuration (continued)

Application and Data Source Retargeting Review all applications targeted to the managed server instance in the WebLogic administration console. Retarget applications and libraries that comprise Oracle Access Manager server. It is not necessary to retarget administrative applications, such as Oracle Access Manager administration console. Next, review JDBC data sources, and retarget any data sources used by Oracle Access Manager to the cluster. Cloning New Servers Clone as many new WebLogic managed server instances as you need, and add them to the cluster. Restart all the managed server instances in the cluster. Changing the Request Cache Type from the BASIC Type to the COOKIE Type Next, you can change the cookie request type from the BASIC type to the COOKIE type. This optional configuration change causes information normally maintained in the URL string during authentication to instead be maintained in the OAM_REQ cookie. You should make this change if your users' browsers enforce small size limits on the length of the URL string. This option enables you to decrease the URL size. Use the following WLST command to change the cache request type: configRequestCacheType(type="COOKIE") After changing the cache request type, you must restart all the managed server instances in the WebLogic cluster. Installing and Configuring the Load Balancer Next, you place a hardware load balancer, software load balancer, or Web proxy in front of managed server instances in the WebLogic cluster. The steps you follow depend on the type of load balancer you choose.

You must configure the Oracle Access Manager server to be aware of the load balancer. In the console, change the host name and port number in the SSO engine configuration to the load balancer's host name and port.
After changing the SSO engine host name and port number, you must restart all the managed server instances in the WebLogic cluster.

Oracle Access Manager 11g R2: Advanced Administration 3 - 18

Converting a Single OAM Server to a Clustered Configuration (continued)

Reconfiguring Agents Agents that previously communicated directly with the Oracle Access Manager server must be reconfigured to communicate with the load balancer. To reconfigure agents: Modify the agent configuration parameters to contain the cluster members' hosts and OAP port numbers. Note that agent HA is based on a primary/secondary failover model. Re-register the agent. Copy the agent artifacts to the agent configuration. Restart the agent.

Oracle Access Manager 11g R2: Advanced Administration 3 - 19

Handling Administration Server Failure in a Cluster of Oracle Access Manager Instances

If the WebLogic administration server goes down, the managed servers running Oracle Access Manager server remain active. But the administrative UIsthe Oracle Access Manager console and the WLST commandare no longer available, and you cannot change the WebLogic Server or Oracle Access Manager configuration. If the domain contains clustered server instances, the load balancing and failover capabilities supported by the domain configuration remain available, even if the administration server fails. You can start a managed server even if the administration server is not running. In this case, the managed server uses a local copy of the domains configuration files for its starting configuration and then periodically attempts to connect with the administration server. When it connects, it synchronizes its configuration state with that of the administration server.

Oracle Access Manager 11g R2: Advanced Administration 3 - 20

Handling Administration Server Failure in a Cluster of Oracle Access Manager Instances (continued)
Starting a Standby Administration Server After an Administration Server Failure The reference architecture provides for a standby administration server on each host running redundant Oracle Access Manager servers. When you propagate the WebLogic domain to multiple hosts running clustered managed server instances, a copy of the administration server is also propagated. The slide shows the presence of two administration servers in the deployment, with one administration server active and the other administration server available as a standby. In normal operation, all the managed server instances run, while only a single administration server runs. In the event of an administration server failure, one of the standby instances can be brought up to service requests for configuration changes.

Oracle Access Manager 11g R2: Advanced Administration 3 - 21

Data Tier
Oracle Access Manager uses the following types of data, which reside on the data tier: Audit data Oracle Access Manager policies Oracle Access Manager sessions Identity data For Oracle Access Manager 11g R1, audit data, policies, and sessions are always stored in an Oracle Database. A typical strategy for Oracle Database HA is Oracle Real Application Clusters (Oracle RAC). Refer to the following URL for more information about Oracle Database high availability, including Oracle RAC: http://www.oracle.com/technetwork/database/features/availability/ index.html. If you use Oracle Internet Directory for your identity store, then identity data is stored in an Oracle Database instance. Use Oracle RAC or another Oracle Database HA strategy. If you use a non-Oracle product for your identity store, refer to your vendor's documentation for information about making the identity store highly available.

Oracle Access Manager 11g R2: Advanced Administration 3 - 22

Other Issues to Be Aware of in HA Deployments

When deploying Oracle Access Manager in an HA environment, a number of issuessuch as the issues listed on the slidethat are beyond the scope of this course come into play. Although these issues are not covered in this course, you should be aware of them and be prepared to handle them, depending on your organization's needs.

Oracle Access Manager 11g R2: Advanced Administration 3 - 23

Oracle Access Manager 11g R2: Advanced Administration 3 - 24

Session and Configuration Replication

Oracle Access Manager server uses Oracle Coherence to replicate user sessions and the Oracle Access Manager configuration. The eCO Grid The eCO Grid (embedded Coherence grid) is a high-performance distributed caching system that enables Oracle Access Manager to propagate creation and modifications to user sessions across multiple distributed servers. The nature of the distributed cache system implicitly supports site affinity such that any run-time servers have access to the same set of sessions when serving access requests that may have bounced through multiple servers. Making session stores persistent further empowers eCO Grid. With persistent session stores, it is possible to recover from mass failures in the security environment and maintain the same user sessions once the failures are resolved.

Oracle Access Manager 11g R2: Advanced Administration 3 - 25

Session and Configuration Replication (continued)

Session Replication Oracle Access Manager user sessions are created on the server on which a user authenticates. The number of sessions that can be stored concurrently varies, depending on the following factors: The amount of memory available for session storage on the host The size of user sessions In addition to being stored in-memory on the host, sessions are also written to the Oracle database when they are created or updated. When Oracle Access Manager is running in a clustered environment, with multiple servers running on different hosts, sessions are also replicated to the other hosts on which Oracle Access Manager servers run. Therefore, in the clustered environment, there are three possibilities for session retrieval: Sessions can be retrieved from the same host. Sessions can be retrieved from another host in the cluster. If all the Oracle Access Manager servers in a cluster go down, sessions are recovered from the database as needed after one or more Oracle Access Manager servers are restarted. Session Management Sessions are deleted by Oracle Access Manager as follows: When a user logs out When an administrator deletes the session by using the Oracle Access Manager console After the session lifetime timeout interval has been exceeded An asynchronous process periodically purges expired sessions from the in-memory caches and the database.

Session Cache Size

The Coherence session cache must be sized so that it never runs out of memory. Use the following property in the oam-config.xml file to specify the maximum cache size: DeployedComponent/Server/NGAMServer/Profile/Sme/SessionManagers /ServerSessionManager/DistributedCacheMaxSize You express the DistributedCacheMaxSize propertys value as a value of type memorySize. For example, 100 MB. Note: You cannot use the Oracle Access Manager console or the WLST utility to change the DistributedCacheMaxSize propertys value.

Oracle Access Manager 11g R2: Advanced Administration 3 - 26

Session and Configuration Replication (continued)

Distribution of Configuration Changes Oracle Access Manager also uses the eCO Grid to distribute changes in the Oracle Access Manager configuration to multiple hosts running Oracle Access Manager server. When an administrator changes the Oracle Access Manager configuration, the changes are written to the oam-config.xml file, then pushed through the eCO Grid to all hosts running Oracle Access Manager server. Note: Unlike user sessions, the Oracle Access Manager configuration is not written to the database. Oracle Coherence Instance Used by the eCO Grid The eCO Grid uses a separate instance of Oracle Coherence software that is automatically installed with Oracle Access Manager. The eCO Grid Coherence instance is not the same Coherence instance that you can optionally install when you install WebLogic Server.

Oracle Access Manager 11g R2: Advanced Administration 3 - 27

User Session Continuity in a Single Oracle Access Manager Server Environment

Session replication supports Oracle Access Manager's user session continuity capability. With user session continuity, when an Oracle Access Manager server fails, it is possible for the user to continue to access protected applications without re-authenticating to the server. The slide shows how, in an environment with a single Oracle Access Manager server, sessions can fail over after a server restart because the eCO Grid stores sessions in a database as they are created. The eCO Grid can retrieve sessions from the database if it cannot locate sessions in its memory cache. If sessions resided only in-memory, they would be lost after a server process or host went down, forcing users to re-authenticate after a server restart.

Oracle Access Manager 11g R2: Advanced Administration 3 - 28

User Session Continuity in a Clustered Oracle Access Manager Server Environment

In an environment with a cluster of Oracle Access Manager servers, sessions can fail over without a server restart. If a single Oracle Access Manager server remains up and running, that server can obtain sessions for any user from the eCO Grid. The eCO Grid might retrieve a user's session from any of the following locations: The memory cache on the local host A memory cache on another host The session store in the database, if retrieval from memory caches fails Sticky cookies are not required for user session continuity. The slide shows an environment with two Oracle Access Manager servers. When both servers were up, three users logged in to Oracle Access Manager. Two users' sessions were distributed to other hosts in the eCO Grid, and all the sessions were written to the session store in the database. After one of the servers failed, two users' sessions continued to be available in the eCO Grid. The third session, if needed, could be fetched from the session store.

Oracle Access Manager 11g R2: Advanced Administration 3 - 29

Oracle Access Manager 11g R2: Advanced Administration 3 - 30

Backing up an Oracle Fusion Middleware Deployment

The slide provides an overview of Oracle Fusion Middleware backup. Backing up the Oracle Fusion Middleware Environment

It is important to consider your entire Oracle Fusion Middleware environment when performing backup and recovery. The installations of an Oracle Fusion Middleware environment are interdependent in that they contain configuration information, applications, and data that are kept in synchronization. For example, when you perform a configuration change, information in configuration files is updated. When you deploy an application, you might deploy it to all managed servers in a domain or cluster.
You should back up your entire Oracle Fusion Middleware environment after installation, then regularly. If a loss occurs, you can restore your environment to a consistent state. The backup strategy proposed in the Oracle Fusion Middleware Administrator's Guide is to perform full backups when the system is downafter installation, upgrading, and patching and backups of run-time artifacts regularly.

Oracle Access Manager 11g R2: Advanced Administration 3 - 31

Backing up an Oracle Fusion Middleware Deployment (continued)

Static Files and Directories: Backed up During Full Backups Only Static files and directories change rarely. The Oracle Fusion Middleware Administrator's Guide recommends backing up the following files only when the environment is fully shut down: The Middleware home directory The OraInventory directory The OraInst.loc and oratab files The beahomelist file For Windows installations, the following registry nodes: HKEY_LOCAL_MACHINE\Software\oracle HKEY_LOCAL_MACHINE\System\ControlSet001\Services HKEY_LOCAL_MACHINE\System\ControlSet002\Services HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services

Run-Time Artifacts: Backed up During Full Backups and Regular Backups Run-time artifacts can change often. The Oracle Fusion Middleware Administrator's Guide recommends backing up the following files on a regular basis, typically nightly: Domain directories Oracle instance homes Applications artifacts, such as .ear and .war files, that reside outside of the domain Database artifacts, such as the policy and audit data store The identity store, which might or might not reside in an Oracle database

When performing the backup of run-time artifacts, do not back up local audit files if your Oracle Access Manager deployment is configured to write audit records to the database. Duplicate records might be uploaded to the audit database after a restore.

Backup Utilities
Oracle Fusion Middleware does not provide users with any special backup utilities or tools. You use tools provided with operating systems or other software: For file backup, use tools such as the tar utility on Linux and UNIX, and the xcopy command on Windows. For database backup, use Oracle Recovery Manager. For more information about Oracle Recovery Manager, refer to the Oracle Database Backup and Recovery User's Guide. For registry key backup, use the regedit utility or any other registry backup tool. For identity store backup, use Oracle Recover Manager for Oracle Internet Directory. If you use a different identity data store, refer to the documentation for the backup procedure for the identity store.

Oracle Access Manager 11g R2: Advanced Administration 3 - 32

Recovering Your Environment

The slide provides a list of different types of failures and outages that might occur during operation of an Oracle Access Manager deployment. The notes provide brief overviews of the steps you take to recover from the failures and outages. For complete information about recovery procedures, refer to the Oracle Fusion Middleware Administrator's Guide. Recovering a Middleware Home 1. Stop all processes related to the domain, such as the administration server, managed servers, and node managers. 2. Recover the Middleware from backup. 3. Restart domain processes.

Oracle Access Manager 11g R2: Advanced Administration 3 - 33

Recovering Your Environment (continued)

Recovering a Domain 1. Stop all processes related to the domain, such as the administration server, managed servers, and node managers. 2. Recover the domain directory from backup. 3. Restart domain processes. Recovering Oracle Homes 1. Recover the Oracle home to its original directory from backup. 2. Restart managed servers to which the applications are deployed. Recovering Instance Homes Perform the following procedure if the instance home was deleted from the file system: 1. Stop any processes related to the instance. 2. Recover the instance directory from backup. 3. Restart instance processes. Perform the following procedure if the instance was deregistered from the domain: 1. Recover the instance directory from backup. 2. Register the instance and all of its components with the administration server by using the opmnctl registerinstance command. Recovering the Administration Server Configuration 1. Stop all processes related to the domain, such as the administration server, managed servers, and node managers. 2. Restore the domain home backup to a temporary location. 3. Restore the config directory to the DOMAIN_HOME/config directory. 4. Restart the administration server and verify that it is accessible. 5. Restart other domain processes.

Recovering Managed Servers

Procedures for recovering managed servers vary, depending on the failure. Refer to the Oracle Fusion Middleware Administrator's Guide for managed server recovery scenarios. Recovering Data in the Data Tier To recover audit data, policy data, and identity store data for Oracle Internet Directory, use Oracle Database Recovery Manager. For more information about Oracle Recovery Manager, refer to the Oracle Database Backup and Recovery User's Guide. For other identity stores, refer to the documentation for the identity store.

Oracle Access Manager 11g R2: Advanced Administration 3 - 34

HA Topology Review
The diagram on the slide provides a reference topology for high availability Oracle Access Manager deployments. While your specific deployment might differ in some areas, the reference topology is a good starting point for complex Oracle Access Manager deployments. Some deployment elements on the slide have been covered earlier in this lesson. For example: Redundancy on the Web, application, and data tiers Usage of load balancers Other deployment elements on the slide are not in the scope of this lesson but are important to consider when configuring a high availability deployment. For example: Placement of firewalls Port numbers to be opened in firewalls Redundancy of the directory service

Oracle Access Manager 11g R2: Advanced Administration 3 - 35

Oracle Access Manager 11g R2: Advanced Administration 3 - 36

Answer: b

Oracle Access Manager 11g R2: Advanced Administration 3 - 37

Oracle Access Manager 11g R2: Advanced Administration 3 - 38