Uninstalling Oracle Access Manager Components

During Oracle Access Manager component installation, information is saved after certain operations. Until information is saved, you may return and restate details. However, after you are informed that a component is being installed, Oracle Access Manager files are added to the file system.

Note:

If you cancel the installation process after receiving the message that a component is being installed and before completing all procedures, you must restore the system to it's previous condition to remove Oracle Access Manager-related information.

There are several steps you need to complete to remove an Oracle Access Manager component, as outlined in the discussion that follows. Some changes made for Oracle Access Manager are not handled automatically and must be manually removed when the Uninstaller program finishes:

Language Packs: Each installed Language Pack must be removed individually using appropriate file in the component's uninstall directory: Component_install_dir\identity|access\_uninstComponentLP_langtag\uninstaller.exe. For example, suppose you have an Identity Server and the WebPass installed with a Korean Language Pack. After uninstalling the Korean Language Pack on each component host, you must stop and restart both the Identity Server Service and the WebPass Web server instance. This will re-initialize corresponding components with the proper language support. Removing the Language Pack associated with the default Administrator language selected during installation is not supported.

Schema and Data Changes: If Oracle Access Manager will be removed and reinstalled with the same directory instance, only the Oracle Access Manager configuration tree(s) need be deleted. In this case, there is no need to remove the Oracle Access Manager schema from the directory instance. When reinstalling the Identity Server, select ÒNoÓ when asked if you want to update the schema (which is already present). Selecting ÒYesÓ results in an error message "schema already exists".

If, however, you plan to remove and reinstall Oracle Access Manager a different directory instance (or not reinstall at all) then configuration data must be removed manually from the directory server and Oracle Access Manager schema extensions must also be removed using cleanup files provided for your directory server. You must remove data from the Identity Server and Policy Manager.

Depending on the type of directory server, you may have one or two cleanup files. For instance, schema extension cleanup files are provided for user data only for VDS. However schema extension cleanup files are provided for both user data and Oblix (configuration data) for NDS, IPlanet, and Oracle Internet Directory. Schema extension cleanup file names begin with an abbreviation that identifies the type of directory, followed by the type of data to be removed.

As an example, look for the files similar to the following in the Identity Server and Policy Manager installation directories:

• DirectoryName_user_schema_delete.ldif—Oracle Access Manager user data cleanup file for the specific named directory—removes user data that resides on a separate directory instance from configuration data
  
• DirectoryName_oblix_schema_delete.ldif—Oracle Access Manager configuration data cleanup file for the specific named directory—removes both user and configuration data when both reside on the same directory instance
  
• OID_oblix_schema_index_delete.ldif—Oracle Access Manager cleanup file for Oracle Internet Directory only—removes the Oracle Access Manager attribute index from Oracle Internet Directory before or after you use corresponding Oracle Access Manager data and schema cleanup files.
  
• OID_user_index_delete.ldif—Oracle Access Manager cleanup file for Oracle Internet Directory only when a separate instance is used to host user data.
  

Some directory vendors do not provide schema cleanup files. For instance, no such files are provided for ActiveDirectory, and Active Directory Application Mode (ADAM).

Web Server Configuration Changes: Web server configuration changes that occur during installation must be manually reverted after uninstalling the Oracle Access Manager component (WebPass, Policy Manager, WebGate). For example, the ISAPI transfilter will be installed for IIS WebPass. However, when you uninstall WebPass this is not removed automatically. Also, the created Web service extension and the link to the identity directory will not be removed. This type of information must be removed manually. These are examples of information to remove, not a complete list. Further, you must remove any changes that you manually made to your Web server configuration file for the Oracle Access Manager component (WebPass, Policy Manager, WebGate) should be removed. For more information about what is added for each component

Tuning Apache 1.3 for Oracle Access Manager Web Components

The purpose of this note is to address some consideration for tuning Tuning Apache 1.3 for Oracle Access Manager Web Components.

Tuning Apache 1.3 for Oracle Access Manager Web Components

Apache 1.3 uses a process model for serving multiple http requests at once. This is different from the single process (thread) model employed by other Web servers, which manage several requests simultaneously in one process.

Each subordinate Apache worker-process responds to an incoming http request independently of every other worker-process. Several parameters in the Apache server configuration file (httpd.conf) affect how an Apache server decides to create or destroy worker processes.

The following affect the performance of the server:

MaxServers: The number of simultaneous http requests that a system can handle depends on the maximum performance of the system.

Performance Tuning: Performance tuning for a system should be done using an http load generating tool such as the ab program supplied with Apache.

MaxSpareServers: Sets the desired maximum number of idle child server processes. An idle process is one which is not handling a request. If there are more than MaxSpareServers idle, then the parent process will kill off the excess processes.

To preserve as much state as possible in the server, set the MaxSpareServers to a high value.

Setting this value to the maximum of 255 keeps all Apache worker-processes available indefinitely, but it does not provide an opportunity for worker-process recycling during low-load periods.

MaxClients: Sets the limit on the number of simultaneous requests that can be supported. As child processes are spawned to handle requests, no more than MaxClients number of processes will be created. Any connection attempts over the MaxClients limit will normally be queued, up to a number based on the ListenBacklog directive. Once a child process is freed at the end of a different request, the connection is then serviced.

To configure more than 256 clients the HARD_SERVER_LIMIT entry in httpd.h must be modified and Apache must be recompiled. With a high MaxClients setting and high load, the server will attempt to serve all requests immediately.

Memory constraints must be taken into account when setting this option. If the memory consumption of a child process (~1 MB in plain Apache, ~10 MB with mod_perl enabled) multiplied by the number of running child processes is larger than available system memory, then child processes will be swapped out of main memory to disk. A high number of disk swaps can have a severe impact on server performance.

MaxClients should be configured as small as possible to preserve performance. Calculation of this value is straight-forward:
MaxClients = (Total RAM dedicated to web server) / (Child's max memory consumption) Or, taking into account memory shared by child processes:

MaxClients = (Total_RAM – Min_Shared_RAM_per_Child) / (Max_Child_Process_Size – Min_Shared_RAM_per_Child)

MaxRequestsPerChild: The MaxRequestsPerChild directive sets the limit on the number of requests that an individual child server process will handle. After MaxRequestsPerChild requests, the child process will die. If MaxRequestsPerChild is 0, then the process will never expire.

The primary purpose of this option is as a safety mechanism. Regularly recycling child processes prevents poorly behaving child processes from consuming memory resources. This safety mechanism is not unreasonable, but the start-up delay for Oracle Access Manager Web components (also known as plug-ins) is noticeable at the Web browser.

If you use this parameter, set it high enough for end users to rarely notice the startup delay. Oracle Access Manager plug-ins are designed to run under Web servers without this safety mechanism.
ThreadsPerChild

Available only with Apache 1.3 running on Windows. This directive tells the server how many threads it should use. This is the maximum number of connections the server can handle at once; be sure and set this number high enough for your site if you get a lot of hits.

This directive has no effect on Unix systems. Unix users should look to StartServers and MaxRequestsPerChild.

MinSpareServers: Sets the desired minimum number of idle child server processes. An idle process is one that is not handling a request.

If there are fewer than MinSpareServers idle, then the parent process creates new children at a maximum rate of 1 every second. Use this with the Policy Manager.

Note:

Setting this directive to some value m ensures that you will always have at least n + m httpd processes running when you have n active client requests.

Because of the fact that Oracle Access Manager plug-in initialization is deferred until the first request, using a high value for the MinSpareServers parameter provides minimal advantage.

However, it is useful to keep this parameter as high as possible. For dedicated Web server systems, this should pose no great burden.

StartServer: As with the MinSpareServers parameter, the advantage of the StartServers parameter is limited by the delayed initialization of the Oracle Access Manager plug-ins.

Appropriate values for the preceding parameters depend on the expected load and the performance class of the systems involved, including the Access Server and LDAP server. Apache servers on very high performance systems with high expected loads may be recompiled with a larger limit on the number of worker processes.

These systems may see a greater performance impact on the StartServers and MinSpareServers parameters for dealing with sudden load spikes.
You may need to adjust operating system limits for the Access Server for proper operation. In particular, the maximum number of file descriptors available for any one Access Server may need to be increased beyond the default value.

Configuring more than one connection between each Apache-based WebGate and an Access Server may quickly exceed this limit.
Access Server Tuning and Resolving Bottlenecks

Configuration of Apache 1.3 has an impact through the chain of communication from the WebGate to Access Server. Configuration changes may need to take place at Access Server, WebGate, and Apache levels to achieve desired performance levels and avoid bottlenecks. The four major configuration options are:

1. The number of Access Server connections allocated to the WebGate
2. The MaxClient Apache configuration option
3. The ThreadsPerChild Apache configuration option (on Windows only)
4. Number of Access Servers and/or number of Service Threads allocated to the Access Server(s)

Fine-tuning WebGate Connections to Access Server:

Take the following hypothetical examples:

Assumption: Access Server services each WebGate request in one second.

Configuration Scenario 1:
One Access Server (60 service threads) configured with one WebGate (Number of connections from WebGate to Access Server = 1) on Apache 1.3 Windows (MaxClient=1, ThreadsPerChild=60)

To fully utilize Access Server's 60 service threads, 60 requests per second should be sent by the WebGate. The bottleneck in this scenario is the number of connections from WebGate to Access Server as a single connection will be used by all requests.

Configuration Scenario 2:
One Access Server (60 service threads) configured with one WebGate (Number of connections from WebGate to Access Server = 5) on Apache 1.3 Windows (MaxClient=1, ThreadsPerChild=60)
Scenario 2 eases the bottleneck as 5 connections should be sufficient to handle the 60 req/sec load.

Configuration Scenario 3:
One Access Server (60 service threads) configured with one WebGate (Number of connections from WebGate to Access Server = 1) on Apache 1.3 Windows (MaxClient=2, ThreadsPerChild=30)

Scenario 3 eases the bottleneck by adding another Apache child process to service requests, however each child process may still have contention on the single Access Server connection allocated to it.

Configuration Scenario 4:
One Access Server (60 service threads) configured with one WebGate (Number of connections from WebGate to Access Server = 5) on Apache 1.3 Windows (MaxClient=2, ThreadsPerChild=30)

Scenario 4 uses both approaches.

Fine-Tuning MaxClient:
Configuration Scenario 1:

One Access Server (60 service threads) configured against one WebGate (no of connection from WG to AAA is 5) on Apache (ThreadsPerChild =10).
Assuming still that Access Server handles a request in one second, each thread will generate 1 request per second. Here each process of Apache has 10 threads and so the total rate of requests per Apache child process will be 10 req/sec. To fully utilize Access Server's 60 service threads, we can set the the MaxClient option to 6.

Configuration Scenario 2:
Two Access Server (60 service threads) configured against one WebGate (no of connection from WG to AAA is 5) on Apache (ThreadsPerChild =10).
With two Access Servers, 120 service threads are available to handle requests. To fully utilize these threads, MaxClient may be set to 12
Fine-Tuning ThreadPerChild

Configuration scenario 1:

One Access Server (60 service threads) configured against one WebGate (no of connection from WG to AAA is 5) on Apache (MaxClient=1).
Here we can set ThreadsPerChild to 60.

Configuration Scenario 2:
One Access Server (60 service threads) configured against one WebGate (no of connection from WG to AAA is 5) on Apache (MaxClient=2).
Here we can set ThreadsPerChild to 30.

Configuration Scenario 3:
Two Access Server (60 service threads) configured against one WebGate (no of connection from WG to AAA is 5) on Apache (MaxClient=10).
Here we can set ThreadsPerChild to 12.

Summary:

Achieving the proper balance of options to support desired load requires that the options be taken together. Load requirements or resource constraints tend to dictate one or more of these configuration options and the rest are derived from there.

1. Depending on the load to be supported on the webserver, configure values of MaxClient and ThreadsPerChild as follows
a. Compute MaxClient value
b. ThreadsPerChild = "Number of parallel requests on web server" / MaxClient
2. Once this is done, Access Server and WebGate configurations must be tuned accordingly
a. Threads in each Apache process share the same set of connections to the Access Server. If ThreadsPerChild is high, there may be contention for a small number of connections. To solve this increase the number of connections WebGate has available to it.
b. The maximum number of connections that may be established to Access Server is MaxClient * (Number of WebGate-to-Access Server connections). If this value approaches very high levels, resource constraints (memory, socket, network load) may be reached, causing system stability issues. To solve this, decrease connections or MaxClients.
c. The maximum possible number of requests that may be simultaneously sent to the Access Server is a product of (MaxClient * ThreadsPerChild). If the number of Service Threads configured in Access Server is less than the in-flow of requests, the average wait-time for requests will increase. In this case, increasing the number of service threads in the Access Server or adding additional Access Servers to the environment will help resolve the bottleneck.

Policy Manager Tuning Factors
Policy Manager performance may be impacted by both Apache and Policy Manager configuration parameters.

The following factors should be considered when tuning the Policy Manager for Apache:
• The idle child processes ensure that a new incoming request is serviced immediately. The more spare child processes, the faster the ramp up.
• Each child process opens separate connections to the directory server. The more child processes you have, the more directory server connections you have.
Assuming that each user is using one browser, there are four to five simultaneous requests to the Web server for images and js and HTML from the browser.

Assuming that there are four simultaneous users, the total number of simultaneous requests to the Web server is 4 * 5 = 20.
Given these factors, Oracle recommends the following to maintain a balance between how fast a new user is serviced and the number of connections to the directory server:
• MaxClients = 25

• MinSpareServers = 4

• MaxSpareServers = 5

Note:
The Policy Manager does not open connections on Web Server startup.

Instead, the Policy Manager creates connections on the first request.

To help compensate for any delay when the Policy Manager creates connections, the Policy Manager may be configured such that all directory server connections for all directory server profiles are set to 1

In this case, the Apache configuration may be as follows:
• MinSpareServers = 1

• MaxSpareServers = 2

• MaxServers = 2
In the preceding case, the Policy Manager responds in a reasonable time with some delay on the initial request.