The IMS Server (and its underlying Apache Tomcat and JVM environment) is optimized to support large deployments. It is possible to setup a single server machine hosting IMS and database server or a distributed or highly available solution. When installing IMS, the default parameters used for the database pool and for the underlying Tomcat application server and JVM assumes a
server-class host machine with a SpecIntRate2006 greater than 30 and at least 1 GB of RAM. Usually, adjusting these parameters is not necessary unless the server machine is of lower-end specification (for example, a low-end machine with 512 MB RAM).
You may further optimize the various IMS, Tomcat, and JVM parameters for specific scenarios where the default configuration is found to be sub-optimal.
Because IMS is processor-bound, setting the JVM maximum heap size, for example, greater than 512 M might not have significant performance
improvements in some scenarios. However, a best practice is for tuning to be accompanied by a round of load or stress-testing to verify the performance gains and to ensure the system remains stable under load.
The IMS installer always sets the memory allocation and connection parameters to default values on the first installation. During upgrades, the memory setting is overwritten, while the database connection setting parameter remains the same.
You have to optimize the number of concurrent threads after every upgrade. For specific steps, refer to IBM Tivoli Access Manager for Enterprise Single Sign-On Deployment Guide Version 8.0.1, SC23-9952.
The IMS Server performance tuning parameters can be classified in four types:
Memory allocation, which is the amount of RAM allocated to IMS Server These parameters specify the amount of memory allocated to the JVM.
Connection parameters, which are the number of concurrent connections to be accepted or processed
These parameters control the number of concurrent AccessAgent connections that the IMS Server can handle.
Database parameters, which is the database pool size and timeout values
Note: There are separate configurations for connections to the IMS database (which stores system data, user passwords, and more) and the IMS log database (which stores audit logs), although most of the time, the IMS database and log database reside on the same database server.
RADIUS parameters: The number of concurrent RADIUS requests to be accepted
The optimal values of these parameters depend on many external factors, which vary across deployments:
Number of concurrent AccessAgent connections to IMS Server
Whether IMS Servers are load-balanced
Tasks performed on IMS Server (for example, a deployment using OTP authentication may require more processor power)
Processor speed of IMS Server
Amount of physical RAM that can be allocated to IMS Server
Whether the database server is sharing the same machine with IMS Server
Processor speed of database server
Amount of physical RAM allocated to database server
Capability of the database server (for example, number of concurrent connections it can handle)
Quality of the network (for example, slow network requires higher timeout thresholds for database connections)
Refer to IBM Tivoli Access Manager for Enterprise Single Sign-On Deployment Guide Version 8.0.1, SC23-9952 for more information about IMS Server performance tuning parameters.
6.1.1 Improving server scalability and availability
Let us take a look at two different deployments: small scale and typical.
Small-scale deployment
The IMS and database server can be hosted on a single machine, which is sufficient for small-scale deployments. This configuration can be scaled-up in the following ways:
Enhance the processor hardware (faster processor or multi-processor).
Add more RAM.
Upgrade the disk sub-system (more disks, faster disks) and optimize the database file layout on these disks.
Note: This setting is only required if the RADIUS authentication feature of IMS Server is used.
A single server configuration can be made highly-available by adding a second server and setting up an active-passive cluster over the two servers. Such a configuration typically involves:
Use of Microsoft Cluster Service (or equivalent)
Use of an external disk array shared by both server machines
Use of a cluster-aware edition of the database server
Configuring the cluster service to recognize IMS and the database as resources to be managed under the cluster
In such a configuration, the cluster service monitors the following elements:
Host machines
Health of the IMS Server
Database services
The cluster service can trigger a failover from one machine to another if any of the elements fail.
Typical deployment
For most deployments, a two-tier architecture is good practice, with a tier of IMS Servers fronting a shared database server.
In this configuration, a hardware or software-based load-balancing solution should be used to distribute the incoming traffic from various AccessAgent installations into multiple IMS Servers. The load-balancing solution should support session affinity, where each client’s request is consistently routed to the same IMS Server (until the server goes down, and the requests are then re-routed to another server). Such load balancers inspect each packet’s IP headers and route it to one of the IMS Server farm members based on some rule (for example, client IP address, destination port, and so on).
The load balancers automatically re-balances incoming traffic when a member of the server farm goes up or down. Some load balancers also support continuous monitoring of application or service status based on custom scripts (for example, pinging a certain URL), so that traffic can be re-routed if a certain application or service on a server machine fails to respond.
An example software-based load balancing solution is the Microsoft Network Load Balancing (NLB) solution, which is packaged with the Windows Server platform. In a Microsoft NLB setup, all member servers share the same DNS name and virtual IP address. Each server has its own private IP address, for heartbeat checks and administration purposes. Incoming traffic is routed to all servers but only one server accepts and processes the request. NLB can be
configured to support session affinity, where the client’s IP address is used to determine which member server to accept the request.
A load balancing solution is also often used to provide High Availability. Refer to IBM Tivoli Access Manager for Enterprise Single Sign-On Deployment Guide Version 8.0.1, SC23-9952 for details.
You scale up the database server if performance measurements indicate that its processor, RAM, or disk is a bottleneck. As such, the methods for scaling up the database server includes:
Enhance the processor hardware (faster processor or multi- processor).
Add more RAM.
Upgrade the disk sub-system (more disks, faster disks) and optimize the database file layout on these disks.
Solutions for scaling out the database server across multiple machines are typically vendor-dependent (for example, Oracle RAC, IBM DB2 DPF, and so on) and might require customization to the IMS installation process to interoperate with such solutions.
6.1.2 Distributed IMS using replicated databases
A previous limitation of the IMS architecture was that all IMS Servers had to share a single database instance. This precluded large enterprises from
deploying IMS in a distributed fashion. Even if the IMS Servers can be distributed in multiple sites (for example, one in New York, one in Los Angeles, and one in Singapore), they must ultimately connect back to the single IMS DB server installed at one site.
This single database instance limitation is an issue for large customers, for reasons such as:
The IMS site (and the IMS database) becomes a single point of failure.
A lot of unnecessary cross-site traffic might occur between AccessAgent and IMS, because AccessAgent systems will not be in the same site as IMS.
Scaling the IMS database might be I difficult and expensive because the only way to handle higher load volumes is by upgrading the DB server hardware.
For some large customers, the workaround is to set up separate logical IMS Servers for each region. Each region’s users will have a separate IMS setup (one IMS and one DB), with its own set of users, profiles, and policies. However, this solution has limitations because AccessAgent can only support one IMS at a time. A user from one site cannot log in to AccessAgent from a machine
configured at another site. You can have an architectural solution that allows each major geographic region and site to host its own set of IMS and IMS DB servers (service AccessAgent systems in its respective region), while allowing users to occasionally roam from one site to another.
Database replication is a solution that allows IMS databases to replicate with across sites reliably and quickly. Because database replication technologies vary for each vendor, Tivoli Access Manager for Enterprise Single Sign-On supports only database replication for DB2 for this release.
For more information about distributed IMS, refer to IBM Tivoli Access Manager for Enterprise Single Sign-On Deployment Guide Version 8.0.1, SC23-9952.