CAPITULO III: Dinámicas de control territorial y desterritorialización
3.4 CONCLUSIONES
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Objectives
After completing this lesson, you should be able to:
•
Describe high availability goals
•
Mitigate potential points of failure in an OAM deployment
•
Provide high availability for OAM sessions and
configuration data stored in XML files
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Road Map
•
Objectives
•
High availability goals
•
Mitigating potential points of failure
•
High availability for OAM sessions
and configuration
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.
In an HA deployment, Oracle Access Manager is available for use all the time or nearly all the time. 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
High Availability (HA) Goals
•
Minimize down time
•
Provide user session continuity
•
Provide recovery from data loss or corruption
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Road Map
•
Objectives
•
High availability goals
•
Mitigating potential points of failure
•
High availability for OAM sessions
and configuration
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Potential Points of Failure in an
Oracle Access Manager Deployment
Web Tier Application Tier Database Tier Audit and Policy LDAP
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 server—the audit database, policy database, session database, and identity store—comprise 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 database’s 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 servers—the resources that Oracle Access Manager protects—can 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.
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 balancers—for example, Cisco Local Director or F5 Networks BIG-IP— provide speed, high reliability, and advanced features.
• Software load balancers—for example, the reverse proxy plug-in for Oracle HTTP Server—are 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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Load Balancing on the Web Tier
Load Balancer Redundant Oracle Access Manager Agents Application Tier
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.
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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.