oracle access manager high availability training class
DESCRIPTION
Oracle Access Manager High Availability Training ClassTRANSCRIPT
-
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 re-
authenticating.
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-IPprovide 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 patchingand 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