Capacity Planning Guide

Transcription

1 IBM Tioli Access Manager Capacity Planning Guide GC

2

3 IBM Tioli Access Manager Capacity Planning Guide GC

4 Note: Before using this information and the product it supports, read the information in Notices on page 19. Second Edition (March 2002) This edition replaces GC Copyright International Business Machines Corporation 2001, All rights resered. US Goernment Users Restricted Rights Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

5 Contents Preface Who should read this book What this book contains Publications IBM Tioli Access Manager Related publications iii Accessing publications online ix Ordering publications ix Proiding feedback about publications x Accessibility x Contacting customer support x Conentions used in this book x Typeface conentions x Capacity planning Capacity planning process Understanding network topology choices Serers in a WebSEAL enironment WebSEAL network topology choices Physical networks Identifying serer transactions Transactions in a WebSEAL enironment Defining serer transaction throughput requirements Basing estimates on empirical data Basing estimates on registered users Choosing hardware Memory and disk storage planning Obtaining measurements/throughput rates Modifying transaction types to match measurement reports Scaling for hardware differences Scaling for CPU utilizations less than 100% Scaling for differences in page sizes Scaling for page size and imbedded images Scaling for physical network differences Calculating the required number of machines Increasing the number of machines Making network topology choices Capacity planning example Understanding network topology choices Identifying serer transactions Defining serer transaction throughput requirements Choosing hardware Obtaining measurements/throughput rates Calculate the required number of machines Make network topology choices Notices Trademarks Index Copyright IBM Corp. 2001, 2002 iii

6 i Access Manager: Capacity Planning Guide

7 Preface Who should read this book What this book contains Publications IBM Tioli Access Manager (Access Manager) is the base software that is required to run applications in the Access Manager product suite. It enables the integration of Access Manager applications that proide a wide range of authorization and management solutions. Sold as an integrated solution, these products proide an access control management solution that centralizes network and application security policy for e-business applications. Note: IBM Tioli Access Manager is the new name of the preiously released software entitled Tioli SecureWay Policy Director. Also, for users familiar with the Tioli SecureWay Policy Director software and documentation, the term management serer is now referred to as policy serer. The IBM Tioli Access Manager Capacity Planning Guide assists planners in determining the number of WebSEAL, LDAP, and backend Web serers needed to achiee a required workload. This guide is for system administrators responsible for the installation and deployment of Access Manager. Readers should be familiar with the following: System administrators Installation planners responsible for planning the deployment of Access Manager and WebSEAL. Chapter 1, Capacity planning on page 1 Proides an introduction for considerations that need to be addressed in the planning stages of deployment of the Access Manager product suite. Subjects addressed are network topology, serer transactions, hardware requirements, scaling, and an example of capacity planning. This section lists publications in the Access Manager library and any other related documents. It also describes how to access Tioli publications online, how to order Tioli publications, and how to make comments on Tioli publications. IBM Tioli Access Manager The Access Manager library is organized into the following categories: Release information Base information WebSEAL information Web security information Deeloper reference information Supplemental technical information Copyright IBM Corp. 2001, 2002

8 For additional sources of information about Access Manager and related topics, see the following Web sites: Release information IBM Tioli Access Manager for e-business Read Me First, GI (am39_readme.pdf) Proides information for installing and getting started using Access Manager. IBM Tioli Access Manager for e-business Release Notes, GI (am39_relnotes.pdf) Proides late-breaking information, such as software limitations, workarounds, and documentation updates. Base information IBM Tioli Access Manager Base Installation Guide, GC (am39_install.pdf) Explains how to install, configure, and upgrade Access Manager software, including the Web portal manager interface. IBM Tioli Access Manager Base Administrator s Guide, GC (am39_admin.pdf) Describes the concepts and procedures for using Access Manager serices. Proides instructions for performing tasks from the Web portal manager interface and by using the pdadmin command. IBM Tioli Access Manager Base for Linux on zseries Installation Guide, GC (am39_zinstall.pdf) Explains how to install and configure Access Manager Base for Linux on the zseries platform. WebSEAL information IBM Tioli Access Manager WebSEAL Installation Guide, GC (amweb39_install.pdf) Proides installation, configuration, and remoal instructions for the WebSEAL serer and the WebSEAL application deelopment kit. IBM Tioli Access Manager WebSEAL Administrator s Guide, GC (amweb39_admin.pdf) Proides background material, administratie procedures, and technical reference information for using WebSEAL to manage the resources of your secure Web domain. IBM Tioli Access Manager WebSEAL Deeloper s Reference, GC (amweb39_deref.pdf) Proides administration and programming information for the Cross Domain Authentication Serice (CDAS), the Cross Domain Mapping Framework (CDMF), and the Password Strength Module. IBM Tioli Access Manager WebSEAL for Linux on zseries Installation Guide, GC (amweb39_zinstall.pdf) Proides installation, configuration, and remoal instructions for WebSEAL serer and the WebSEAL application deelopment kit for Linux on the zseries platform i Access Manager: Capacity Planning Guide

9 Web security information IBM Tioli Access Manager for WebSphere Application Serer User s Guide, GC (amwas39_user.pdf) Proides installation, remoal, and administration instructions for Access Manager for IBM WebSphere Application Serer. IBM Tioli Access Manager for WebLogic Serer User s Guide, GC (amwls39_user.pdf) Proides installation, remoal, and administration instructions for Access Manager for BEA WebLogic Serer. IBM Tioli Access Manager Plug-in for Edge Serer User s Guide, GC (amedge39_user.pdf) Describes how to install, configure, and administer the plug-in for IBM WebSphere Edge Serer application. IBM Tioli Access Manager Plug-in for Web Serers User s Guide, GC (amws39_user.pdf) Proides installation instructions, administration procedures, and technical reference information for securing your Web domain using the plug-in for Web serers. Deeloper references IBM Tioli Access Manager Authorization C API Deeloper s Reference, GC (am39_authc_deref.pdf) Proides reference material that describes how to use the Access Manager authorization C API and the Access Manager serice plug-in interface to add Access Manager security to applications. IBM Tioli Access Manager Authorization Jaa Classes Deeloper s Reference, GC (am39_authj_deref.pdf) Proides reference information for using the Jaa language implementation of the authorization API to enable an application to use Access Manager security. IBM Tioli Access Manager Administration C API Deeloper s Reference, GC (am39_adminc_deref.pdf) Proides reference information about using the administration API to enable an application to perform Access Manager administration tasks. This document describes the C implementation of the administration API. IBM Tioli Access Manager Administration Jaa Classes Deeloper s Reference, SC (am39_adminj_deref.pdf) Proides reference information for using the Jaa language implementation of the administration API to enable an application to perform Access Manager administration tasks. IBM Tioli Access Manager WebSEAL Deeloper s Reference, GC (amweb39_deref.pdf) Proides administration and programming information for the Cross Domain Authentication Serice (CDAS), the Cross Domain Mapping Framework (CDMF), and the Password Strength Module. Technical supplements IBM Tioli Access Manager Performance Tuning Guide, GC (am39_perftune.pdf) Proides performance tuning information for an enironment consisting of Access Manager with IBM SecureWay Directory defined as the user registry. Preface ii

10 IBM Tioli Access Manager Capacity Planning Guide, GC (am39_capplan.pdf) Assists planners in determining the number of WebSEAL, LDAP, and backend Web serers needed to achiee a required workload. IBM Tioli Access Manager Error Message Reference, SC (am39_error_ref.pdf) Proides explanations and recommended actions for the messages produced by Access Manager. The Tioli Glossary includes definitions for many of the technical terms related to Tioli software. The Tioli Glossary is aailable, in English only, at the following Web site: Related publications This section lists publications related to the Access Manager library. IBM DB2 Uniersal Database IBM DB2 Uniersal Database is required when installing IBM SecureWay Directory, z/os, and OS/390 SecureWay LDAP serers. DB2 information is aailable at the following Web site: IBM SecureWay Directory IBM SecureWay Directory, Version 3.2.2, is shipped on the IBM Tioli Access Manager Base CD for your particular platform. If you plan to install the IBM SecureWay Directory serer as your user registry, the following documents are aailable in the /doc/directory path on the IBM Tioli Access Manager Base CD for your particular platform: IBM SecureWay Directory Installation and Configuration Guide, SC (aparent.pdf, lparent.pdf, sparent.pdf, wparent.pdf) Proides installation, configuration, and migration information for IBM SecureWay Directory components on AIX, Linux, Solaris, and Microsoft Windows operating systems. IBM SecureWay Directory Release Notes (relnote.pdf) Supplements IBM SecureWay Directory, Version 3.2.2, product documentation and describes features and functions made aailable to you in this release. IBM SecureWay Directory Readme Addendum (addendum322.pdf) Proides information about changes and fixes that occurred after the IBM SecureWay Directory documentation had been translated. This file is in English only. IBM SecureWay Directory Serer Readme (serer.pdf) Proides a description of the IBM SecureWay Directory Serer, Version IBM SecureWay Directory Client Readme (client.pdf) Proides a description of the IBM SecureWay Directory Client SDK, Version This software deelopment kit (SDK) proides LDAP application deelopment support. SSL Introduction and ikeyman User s Guide (gskikm5c.pdf) Proides information for network or system security administrators who plan to enable SSL communication in their Access Manager secure domain. iii Access Manager: Capacity Planning Guide

11 IBM SecureWay Directory Configuration Schema (scparent.pdf) Describes the directory information tree (DIT) and the attributes that are used to configure the slapd32.conf file. In IBM SecureWay Directory Version 3.2, the directory settings are stored using the LDAP Directory Interchange Format (LDIF) format in the slapd32.conf file. IBM SecureWay Directory Tuning Guide (tuning.pdf) Proides performance tuning information for IBM SecureWay Directory. Tuning considerations for directory sizes ranging from a few thousand entries to millions of entries are gien where applicable. For more information about IBM SecureWay Directory, see the following Web site: IBM WebSphere Application Serer IBM WebSphere Application Serer Standard Edition, Version 4.0.2, is installed with the Web portal manager interface. For information about IBM WebSphere Application Serer, see the following Web site: Accessing publications online Publications in the product libraries are included in Portable Document Format (PDF) on the product CD. To access these publications using a Web browser, open the infocenter.html file, which is located in the /doc directory on the product CD. When IBM publishes an updated ersion of one or more online or hardcopy publications, they are posted to the Tioli Information Center. The Tioli Information Center contains the most recent ersion of the publications in the product library in PDF or HTML format, or both. Translated documents are also aailable for some products. You can access the Tioli Information Center and other sources of technical information from the following Web site: Information is organized by product, including release notes, installation guides, user s guides, administrator s guides, and deeloper s references. Note: If you print PDF documents on other than letter-sized paper, select the Fit to page check box in the Adobe Acrobat Print dialog (which is aailable when you click File Print) to ensure that the full dimensions of a letter-sized page are printed on the paper that you are using. Ordering publications You can order many Tioli publications online at the following Web site: publications/cgibin/pbi.cgi You can also order by telephone by calling one of these numbers: In the United States: In Canada: Preface ix

12 In other countries, for a list of telephone numbers, see the following Web site: Accessibility Proiding feedback about publications We are ery interested in hearing about your experience with Tioli products and documentation, and we welcome your suggestions for improements. If you hae comments or suggestions about our products and documentation, contact us in one of the following ways: Send an to pubs@tioli.com. Contacting customer support Complete our customer feedback surey at the following Web site: Accessibility features help a user who has a physical disability, such as restricted mobility or limited ision, to use software products successfully. If you hae a problem with any Tioli product, you can contact Tioli Customer Support. See the Tioli Customer Support Handbook at the following Web site: The handbook proides information about how to contact Tioli Customer Support, depending on the seerity of your problem, and the following information: Registration and eligibility Conentions used in this book Telephone numbers and addresses, depending on the country in which you are located What information to gather before contacting support This guide uses seeral conentions for special terms and actions, operating system-dependent commands and paths, and margin graphics. Typeface conentions The following typeface conentions are used in this book: Bold Italic Monospace Command names and options, keywords, and other information that you must use literally appear in bold. Variables, command options, and alues you must proide appear in italics. Titles of publications and special words or phrases that are emphasized also appear in italics. Code examples, command lines, screen output, file and directory names, and system messages appear in monospace font. x Access Manager: Capacity Planning Guide

13 Capacity planning Capacity planning process Capacity planning is the process of assessing system requirements and ensuring that your IBM Tioli Access Manager enironment has adequate resources to serice requests at an acceptable rate. This guide is intended to coer capacity planning of Access Manager WebSEAL and related serers. Howeer, the techniques described are general enough to be used with other distributed and replicated communication systems. Note that this guide does not contain specific measurements. For performance measurements, refer to Access Manager performance reports or supplement existing measurements with those taken in your own lab. This guide contains the following main sections: Capacity planning process Understanding network topology choices Identifying serer transactions Defining serer transaction throughput requirements Choosing hardware Obtaining measurements/throughput rates Calculating the required number of machines Making network topology choices Capacity planning example The capacity planning process begins with a communication system that supports seeral network topologies and an idea of the type of workload that the communication system is required to handle. The next step in the capacity planning process is to identify the types of transactions that each serer is to handle and to map the workload to indiidual serer throughput requirements. Then choose hardware and gather measurements. In turn, these requirements and measurements are input to a calculation that determines the portion of a machine or number of machines needed for each serer. Lastly, make network topology choices. Copyright IBM Corp. 2001,

14 The following flowchart illustrates the capacity planning process: The accuracy of the planning process is directly related to the accuracy of the throughput requirements and estimates that are inputs to the process. And as with any planning exercise, the result is an estimate and a margin of error is assumed. The margin of error aries depending on many factors, including experience leel, confidence in measurements, and how closely the measurements match the desired transactions. Note that this guide makes no claims as to the margin of error that can be assumed with the use of the described methods. It is up to you, as planner, to decide the margin of error. Understanding network topology choices In a typical communication system, there are seeral choices for network topology. In this context, network topology refers to the distribution of serers among multiple machines and the network connections that result. To understand the network topology, you must identify the serers in the system and gather information about each serer. For example, gather the following information: Determine the function that each serer in the communication system performs and the options it supports. For each serer, determine the other serers with which it communicates. Determine the choices for combining and separating serers. Typically, the choice is flexible. Each serer can run on a separate machine or be combined with other serers. Determine whether serers can be replicated or not. A serer might not support replication, yet still can be replicated. In this case, replication is a manual process. Serers in a WebSEAL enironment In a WebSEAL enironment, seeral serers handle workload. Table 1 lists these serers along with their support for replication. If you plan to deploy additional serers in the same enironment, you also must consider workload for these serers. Table 1. Serers in a WebSEAL enironment Serer WebSEAL (PDWeb) Replication Support Yes, through the use of a network load balancer, such as the IBM enetwork Dispatcher 2 Access Manager: Capacity Planning Guide

15 Table 1. Serers in a WebSEAL enironment (continued) Serer Lightweight Directory Access Protocol (LDAP) Backend Web serers Replication Support Yes, Access Manager can load balance between multiple LDAP serers Might require manual replication. Access Manager can load balance between multiple backend serers. WebSEAL network topology choices Following are some basic WebSEAL network topologies: Single machine: all serers combined WebSEAL Management serer LDAP Two machines: WebSEAL and LDAP on separate machines WebSEAL machine WebSEAL Management serer LDAP machine Three machines: WebSEAL, LDAP, and backend (junctioned) Web serer on separate machines WebSEAL machine WebSEAL Management serer LDAP machine Backend Web serer Capacity planning 3

16 Other topologies exist by separating and replicating serers. For example, you can separate the management serer to its own machine and replicate WebSEAL to multiple machines. In this case, you might use a network load balancer, such as IBM enetwork Dispatcher, to spread the load. You also might replicate LDAP serers and possibly backend Web serers to multiple machines. WebSEAL supports load balancing and failoer between multiple LDAP and backend Web serers. Physical networks Another item to consider regarding network topology is the physical network connection choices. You must determine how many physical networks and line speeds are possible or desired. Again, the purpose of each serer may dictate some of the physical network choices. Network bandwidth might be one reason to require multiple physical networks. If the network is the bottleneck, multiple physical networks can be one way to sole the problem. Higher line speeds are another option. For capacity planning purposes, treat the network like a special type of serer. It handles load. If the choices for physical networks are known, treat each physical network as a separate serer. Otherwise, think of the entire network as one big serer and split it into multiple physical networks if necessary. The physical network supports replication in the sense that is supports sub-netting and multiple IP addresses per machine. Identifying serer transactions After you hae identified all serers in the communication system, the next step is to determine the types of workload that the system is expected to handle. Express the workload as system leel transactions with each system leel transaction broken down into serer leel transactions on one or more serers in the system. This step in the capacity planning process seeks to identify all the transactions that each serer is expected to handle. In this step, it is not necessary to determine the frequency of each transaction. The frequency of each transaction is determined in the next step in the process Defining serer transaction throughput requirements on page 6. For example, consider a WebSEAL enironment in which a high-leel transaction consists of an authenticated Web page access. Assume that page access requires Secure Sockets Layer (SSL), uses LDAP authentication, aerages about 5 KB in size, and flows through a WebSEAL TCP junction. This work request isits the WebSEAL serer, the LDAP serer, a backend Web serer, and the physical network. 4 Access Manager: Capacity Planning Guide

17 The resulting serer transactions are as follows: Table 2. Serer transactions example Serer WebSEAL LDAP Backend Web serer Physical network Transaction SSL authenticated Web page access to a TCP junctioned backend WebSEAL-drien authentication TCP Web page access Approximately 10 KB of traffic, including a small oerhead for LDAP serer communication Transactions in a WebSEAL enironment The primary, high-leel transaction in a WebSEAL enironment is access to a Web page. There are seeral parameters that define Web page access. For example, one parameter is whether the page access includes a user login (authentication). Another transaction in a WebSEAL enironment is the administratie update, such as creating, deleting, listing, and modifying users or ACL entries. Following are some of the parameters that are inoled in defining a transaction in a WebSEAL enironment: WebSEAL serer Page access - TCP or SSL - Authenticated, post-authenticated, not authenticated - If SSL, new browser each request (new SSL session) or same browser (SSL session reuse) - If SSL, the SSL cache size and timeouts - If authenticated, user in Access Manager cache or not - If authenticated, failed login or not - Logout (pkmslogout page request) or not - Junctioned or not junctioned to a backend Web serer - If junctioned, TCP or SSL junction type - If junctioned, backend requires authentication or not - Web page size Administratie - Create, delete, list, or modify a user - Create, delete, list, or modify an ACL LDAP serer Authentication - User from LDAP cache, DB2 cache, or disk (non-cached) - Failed authentication or not - If failed authentication, why? User not found or inalid password - Registry size (number of users) Administratie - Create, delete, list or modify - Update to a LDAP master or propagated to an LDAP replica - If update to a LDAP master, replication setting (on or off) Capacity planning 5

18 - Frequency of propagation (immediate or delayed) - Registry size (number of users) Backend Web serer TCP or SSL Authenticated, post-authenticated, not authenticated Web page size Physical network Number of bytes in each transaction Line speed Defining serer transaction throughput requirements The next step in the capacity planning process is to define the serer transaction throughput requirements for each transaction on each serer. This is when the frequency of each serer transaction is defined. To start, define the system leel transaction throughputs and then map them to serer leel transactions for each of the serers inoled. Deciding upon the frequency of transactions, or throughput, in the communication system is perhaps the hardest part of the capacity planning process. It typically is just an estimate and, as such, can be the biggest source of error when calculating the number of machines required. To reduce the margin of error, it is a good idea to base the estimate on empirical data from production enironments. This is not always possible, so other methods, or a combination of methods, for estimating transaction throughputs are necessary. Basing estimates on empirical data Following are ways to gather empirical data. Take IP packet traces and extract the types of transactions and their frequencies oer time. Ensure that serer logging is on and examine the types and frequencies of transactions. For example, you can determine the frequency of authentications and Web page accesses from such traces. Note that when using such measurements, you must take into account any differences in the measured and planned for enironments. Basing estimates on registered users Another method for estimating transaction throughputs, or requirements, is to base estimates on the number of users in the registry. The idea is that some percentage of these users will use the system in any gien time period. Along with this, there is an idea of what an aerage user does in terms of putting load on the system. For example, the percentage of users in any gien time period is the authentication rate. The authentication rate times the load applied by an aerage user gies the throughput for the aerage workload. Note that this method tends to lead to greater margins of error. Following is an example of this method. Assume that there are 2 million registered users and that approximately 20% of them log in (authenticate) each day. Also assume that each user accesses 10 Web pages per session. The required authentication rate is 4.63 authentications per second as calculated in the following formula: 2,000,000 users * 0.20 percent / 24 hours in a day / 60 minutes in an hour / 60 seconds in a minute = 4.63 auths/sec 6 Access Manager: Capacity Planning Guide

19 The required page access rate is 46.3 pages per second as calculated in the following formula: 4.63 auths/sec * 10 pages per user session = 46.3 pages/sec This seems simple enough. Howeer, when using this formula as an estimation tool, you also must consider a ariety of influencing factors, such as reauthentication considerations and user cache size and timeouts. These considerations are described in the following section and in WebSEAL user cache size and timeouts on page 7. Reauthentication considerations When calculating estimations based upon the total number of registered users, consider how often users reauthenticate. It is good to sanity check this rate by calculating how long it takes for all users to authenticate, assuming no reauthentication. For the preious example, it takes 5 days to authenticate eery user as calculated in the following formula: 2,000,000 users / 4.63 users authenticating per second = seconds to authenticate all users or 5 days A quick way to derie this answer is to consider the original statement that 20% of the users log in per day. This means that it takes 5 days for 100% of them to authenticate. The sanity check is to decide whether all 2,000,000 users authenticate in 5 days or if there is some amount of reauthentication going on. For example, if it is expected that the 20% of the users represent an actie set of users that log in once a day, the 4.63 auths/sec rate is reasonable. Yet if some number of the 20% of users reauthenticates during the day, the 4.63 auths/sec rate is too low. On the other hand, it may seem unrealistic that 400,000 different users, 20% of the total, authenticate in a gien day. Perhaps the rate deried from 20% of the users is meant to include reauthentications. WebSEAL user cache size and timeouts One of the items to consider for reauthentication is the WebSEAL user cache size and timeout setting as specified in the secmgrd configuration file. The default user cache size is 4096 and the default timeout is one hour for actie user and 10 minutes for inactie users. Users can be pushed out of cache and forced to reauthenticate if either the cache becomes full or the timeout is reached. It is a good idea to calculate the minimum of these two times and to determine which of these is the actual limiter in the length of a user session. Taking the 4.63 auths/sec example and the WebSEAL default cache size and timeout alues, the time it takes to fill the cache is about 15 minutes as calculated in the following formula: (4096 user cache / 4.63 user auth/sec) / 60 = 14.7 minutes The 15-minute time to fill the cache is less than the one-hour actie use timeout, so it limits the user session to 15 minutes before haing to reauthenticate (at least when the 4.63 authentication rate is occurring). If user sessions are expected to last longer than 15 minutes, increase the WebSEAL user cache size, timeout alues, or both to allow for longer sessions times. In this example, the 15-minute session time is due to the cache size pushing users out. Now assume the user session is estimated to last 20 minutes and the same Capacity planning 7

20 Choosing hardware 4.63 auths/sec authentication rate is used. The cache size that gies 20 minutes before pushing a user out is 5556, as calculated in the following formula: 20 minutes * 60 seconds * 4.63 auths/sec = 5556 users Note that these calculations are based on a single WebSEAL serer. If the authentication load is spread among multiple WebSEAL serers, be sure to use the effectie rate that is applied to each serer when calculating push out times from WebSEAL s user cache. For example, the oerall 4.63 auths/sec authentication rate becomes 2.32 auths/sec when load balancing between two WebSEAL serers. Use the 2.32 auths/sec when calculating cache sizes and user session times. The choice of hardware might or might not be flexible. You might hae a requirement for a specific type of machine or network or you might need to make the most cost-effectie choice from a range of hardware. In either case, you must choose hardware. To ealuate the cost of different hardware choices, the process can be done iteratiely with a different hardware specification each time. From a machine perspectie, the choices are defined in terms of manufacturer, model number, CPU speed, and number of processors. Often the choice for hardware forces a choice of operating system. This is the case in a WebSEAL enironment. For workload capacity planning purposes, each serer is assumed to hae enough RAM and disk space to run efficiently. From a physical network perspectie, the choices are defined in terms of type of network, such as Ethernet or token ring, fiber optics, line speed, and network adapter card manufacturer. The following sections describe capacity planning issues related to hardware. Memory and disk storage planning Related to capacity planning is planning for memory and disk storage requirements. For each serer in the system, consult the serer product documentation for information on the product s base memory and storage requirements. From that documentation also determine any additional requirements for items, such as cache and registry size. Cache size affects memory requirements. User registry affects disk requirements. Following is information on tunable caches and registry issues in a WebSEAL enironment. WebSEAL, LDAP, and DB2 hae caches for holding authenticated users. WebSEAL has a cache for holding SSL sessions and a cache for Web objects. Memory usage requirements are directly related to cache size and load. The WebSEAL product s registry of choice is IBM SecureWay Directory. IBM SecureWay Directory holds its data in DB2 tables. The disk space requirements are directly related to registry size. 8 Access Manager: Capacity Planning Guide

21 Obtaining measurements/throughput rates In this step of the capacity planning process, you must match all identified serer transactions to real measurements on hardware comparable to that chosen. For capacity planning purposes, you need to gather measurements of maximum throughput rate for each transaction type. Maximum throughput rates are typically gathered by ramping up the load on a serer until throughput leels off and response times become too long. Serer throughput measurements can come from seeral sources, including the proider of the serer software, performance reports from third party performance testing companies, and testing in your own lab. Careful reading of any measurement report is highly recommended to better understand what is being measured. Try to find measurements that most closely match the enironment in which the communication system is to be deployed. One item to obsere is the hardware used for the measurement. Attempt to find measurements that most closely match the hardware that you plan to deploy. Then try locating reports with similar architectures, for example, iew information about IBM RS/6000s if you plan to deploy RS/6000s. Also attempt to match similar CPU speeds, operating systems, and operating system leels. If measurement reports are not aailable or not complete, it becomes necessary to estimate from existing measurements, or take new ones. The following sections explain some common techniques for estimating when transaction types and enironments do not match aailable measurements. Modifying transaction types to match measurement reports If there is no comparable measurement for an identified serer transaction type, it is recommended that you break the identified serer transactions down into multiple lower leel transactions or combine them with others to form a single higher-leel transaction. For example, assume the identified transaction is an authenticated Web page access followed by eight post-authenticated Web page accesses. This transaction is probably not general enough to be found in a measurement report. It is likely that it must be broken down into two transactions: authenticated Web page access and post-authenticated Web page access. Scaling for hardware differences One method for bridging hardware differences is to use published benchmarks, aailable from the following Web site: The Standard Performance Ealuation Corporation (SPEC) proides hardware manufacturers a way to publish the results of certain performance benchmarks. Since communication programs tend to act like integer arithmetic programs, the benchmark of interest is specint. To find specint results, select SPEC CPU95 or SPEC CPU2000 from the Web site. Then select Submitted Results and either SPECint95, SPECint_rate95, SPECint2000, orspecint_rate2000. Capacity planning 9

22 Look for machines of interest in any of the submitted results. If a benchmark result lists both machines, use the results as a ratio to scale between the two machines. The formula is as follows: <performance of machine one> = <performance of machine two> * <specint result for machine one> / <specint result for machine two> If there are no benchmark results listing both machines, it might be possible to use an intermediate machine as a bridge. The intermediate machine must be listed in the benchmark results for both of the machines of interest. In this case, you can use ratios to scale from one machine to the intermediate machine and then from the intermediate machine to the second machine. If a machine does not appear in any benchmark result, it may be similar in architecture to a machine that is listed in the benchmark results. For similar architectures, CPU speed or Mhz ratings are good factors to use for scaling. In this case, use the ratio of the CPU speeds to scale from one machine to another. Operating system differences Although the specint benchmark results display the relatie difference in the performance of two machines, the benchmark results tend to be less accurate at predicting communication software performance when operating systems differ. This is because the integer arithmetic benchmarks do not consider certain operating system-specific differences, such as SMP scaling, I/O processing, and resource usage. You should use a larger margin of error when the operating systems differ between machines being scaled, especially if the transaction of interest includes processing that might be operating system specific. Scaling for CPU utilizations less than 100% Sometimes throughput measurements exist for a transaction, yet the measurements do not represent the maximum throughput for the machine under test. Carefully read measurement reports to determine whether maximum throughputs are being reported. Following are some items to look for. When CPU utilizations are proided, less than maximum throughput might be indicated by less than 100% CPU utilization on the serer being measured. It is typical and good when load-generating and non-measured serers run at less than 100% CPU utilization, but the serer being measured should be close to 100% utilized. When data is proided on throughput as load increases, an indication of less than maximum throughput is a lack of leeling off in the throughput. If response times are proided in such reports, another indication is fairly constant or only slightly increasing response time as load is increased. It is possible to estimate maximum throughput from measurements where less than maximum throughput has been achieed, but it requires knowledge of the CPU utilization. It also results in a larger margin of error, since software systems do not always behae well when they reach or go beyond maximum throughput. Following is the formula for estimating maximum throughput from measured throughput at less than maximum: Maximum throughput = measured throughput / CPU utilization 10 Access Manager: Capacity Planning Guide

23 For example, if throughput is measured at 50% CPU utilization, the estimated maximum throughput is twice the measured rate, since only half (50%) the machine is utilized. Scaling for differences in page sizes For the most part, eery Web page has a different size. If the size of arious Web pages is the only difference among them in terms of the serer transaction definition, all the pages can be treated as one aerage-sized page. For example, if workload requirements identify an aerage user session consisting of three 5 KB page accesses, two 10 KB page accesses, and one 15 KB page access, the equialent page size for capacity planning purposes is 8.3 KB. For this example, the aerage page size is calculated as follows: ((3 * 5 KB pages) + (2* 10 KB pages) + (1 * 15 KB)) / 6 total pages = 8.3 KB aerage page In most cases, it is not possible to find Web page access measurements for the exact page size identified in workload requirements. Measurement reports might instead list the throughputs for two or more different sized pages. Gien the throughput for two Web page accesses in which all other serer transaction parameters are the same, you can estimate the throughput of any generalized page size. The estimate is based on the equation of a line gien two points. Because throughput graphs act like the function y=1/x, you must use the inerse of throughput for the linear extrapolation. First, here is some basic math. For a point to be on the same line as two other points, the slopes of all points on the line must be the same. For example, assume that there are two points, (x1,y1) and (x2,y2). For a third point, (x,y) tobeonthe same line, the following equation must be true: (y - y1) / (x - x1) = (y1 - y2 ) / (x1 - x2 ) Soling for y, we hae the following: y = (x - x1) * (y1 - y2 ) / (x1 - x2 ) + y1 Relating this equation back to page sizes, x represents the page size and y represents the inerse of throughput, which acts like a line. In the following equation, all y s hae been inerted, so that y represents throughput: 1/y = (x - x1) * (1/y1-1/y2) / (x1 - x2) + 1/y1 Soling this for y again, we hae the following: y = 1 / ((x - x1) * (1/y1-1/y2) / (x1 - x2) + 1/y1) In this formula, the ariables hae the following definitions: x is the page size being estimated y is the estimated throughput for a page size of x x1 is the first page size for which there is measured throughput x2 is the second page size for which there is measured throughput y1 is the measured throughput for the first page size y2 is the measured throughput for the second page size Capacity planning 11

24 Scaling for page size and imbedded images Use care when estimating the throughput of a Web page that imbeds multiple objects, such as.gif and.jpg files. You must treat each object, the main page, and all imbedded images as separate Web page accesses. Aeraging the size of the Web pages is recommended (as explained in the preious example). Do not treat the entire set of objects as one large Web page access. In other words, aerage the sizes, not add them together. The transactions are many, not one. The reason that this is important is that the throughput of one large page is much better than multiple small pages. Scaling for physical network differences When the physical network used in a measurement report differs from the physical network being deployed, the difference is usually not a concern in terms of the throughputs that the serers are capable of achieing. This is because line speed differences do not affect the serer s ability to do work. It can be a concern if the network adapter card makes heay use of the CPU. Howeer, this is typically not the case. To guard against this, it is recommended that you use high quality and highly-rated network adapter cards. Physical network differences do affect the network s capacity or throughput. For capacity planning of the physical network, you should obtain measurement reports of the physical network throughput. Alternatiely, the physical network s throughput can be estimated as some percentage of its theoretical rate. For example, a 100 Mbps Ethernet network can easily achiee 7 MB per second rates with file transfer protocol (ftp), which is 70% of the theoretical rate. The physical network capacity tends to be less of a concern since most physical networks achiee high rates of transfer. Een so, it is recommended that you gie some consideration to the physical network capacity. Calculating the required number of machines After you define the transactions and requirements for each serer and match them to measurements, it is time to calculate the number of machines that are needed to satisfy the requirements. The number of machines is based upon the requirements diided by the achieables, or measurements. For example, if the requirements are twice the achieables, the result is two; meaning that two machines are needed to meet the requirements. The ratios are calculated for each transaction type for a gien serer, and then added together to get the full story for that serer. The calculation is repeated for each serer. This includes the physical network, which is treated as a special type of serer for capacity planning purposes. If the number of machines needed is less than one, it represents the portion of a machine that is needed. The formula is as follows: Machine factor = R1/M1 + R2/M2 + R3/M Rn/Mn Variable definitions in this formula are as follows: Machine factor specifies the portion of or number of machines needed for a gien serer. 12 Access Manager: Capacity Planning Guide

25 n specifies the number of transactions identified for the gien serer. R1... Rn specifies the throughput requirements for transactions 1 through n. M1... Mn specifies the throughput measurement for transactions 1 through n. Increasing the number of machines It is a good idea to increase the number of machines needed by some percentage. Reasons include accounting for errors in estimations, future growth, and peak usage. It is recommended that you increase the number of machines by at least 20% to account for these factors. Making network topology choices Capacity planning example If the number of machines needed for a serer is more than one and the machine cannot be replicated, a faster machine is needed. Choose a faster machine and repeat the capacity planning steps for that serer. If the ratio for the physical network is greater than one, the throughput exceeds the aailable bandwidth or line speed. Choose a faster network or diide the communication system into multiple subnets. If the number of machines needed for a serer is less than one, it might be possible to combine it with another serer, which also requires less than one machine. Note that these network topology decisions are based upon workload balancing. Other factors that go into the topology choice include failoer, backup, resource usage, and firewall protection. These factors are beyond the scope of this document. The following example steps you through the capacity planning process for a fictitious company. Understanding network topology choices Assume that network topology choices hae been limited to the following case: WebSEAL used to protect resources on a backend Web serer WebSEAL is placed in a DMZ connecting Internet users on one physical network to Intranet backend Web serers on another physical network. LDAP is used as the registry and resides on the Intranet for security purposes. All serers support replication. Identifying serer transactions Assume that the common parameters that define the Web page access transaction are as follows: Access Manager connects to the backend Web serer using a TCP junction with options that filter the original identity of the user and replace it with one proided by WebSEAL ( B, U, and W options). ACLs are defined in WebSEAL to protect backend Web serer resources. Authentication is tuned as described in the IBM Tioli Access Manager Performance Tuning Guide. The aerage Web page is 10 KB in size. Capacity planning 13

26 Assume that the following high-leel transactions are identified: TCP page A user makes a request for a HTTP (TCP) Web page going through WebSEAL to a backend Web serer. No authentication occurs. SSL authentication page A user makes an initial request for a HTTPS (SSL) Web page going through WebSEAL to a backend Web serer. Authentication occurs. SSL post-authentication page A user makes a subsequent request for a HTTPS (SSL) Web page going through WebSEAL to a backend Web serer. No authentication occurs. The high leel transactions break down to the following serer transactions: Table 3. Serer transactions example Serer WebSEAL LDAP Backend Web serer Internet network Intranet network Transaction 10 KB TCP page access through a TCP junction 10 KB SSL page access with authentication through a TCP junction 10 KB SSL page access, already authenticated through a TCP junction Authentication 10 KB TCP page access, already authenticated (Access Manager authenticates to backend Web serers infrequently as defined by backend serer, infrequent enough to be insignificant) 10 KB Web page requests plus SSL, TCP, HTTP, and IP headers 10 KB Web page requests and 200 byte LDAP lookups plus TCP, HTTP, and IP headers Defining serer transaction throughput requirements Assume that IP traces show that a typical user session consists of the following requests: 3 TCP page 1 SSL page requiring authentication 9 SSL pages after authentication Also assume that the traces show user authentication occurs at a rate of 5 per second. The system-wide throughput requirements are as follows: SSL page accesses requiring authentication: 5 per second SSL page accesses after authentication: 9*5 = 45 per second TCP page accesses: 3*5 = 15 per second 14 Access Manager: Capacity Planning Guide