SecureWay Policy Director Capacity Planning Guidepublib.boulder.ibm.com/tividd/td/SW_30/GC32-0811-00/en_US/PDF/pd38...Tivoli SecureWay Policy Director Capacity Planning Guide ... Tivoli

Tivoli® SecureWay® Policy Director Capacity Planning Guide

Tivoli SecureWay Policy Director Capacity Planning Guide

Copyright Notice© Copyright IBM Corporation 2001. All rights reserved. May only be used pursuant to a Tivoli Systems Software License Agreement, an IBM Software License Agreement, or Addendum for Tivoli Products to IBM Customer or License Agreement. No part of this publication may be reproduced, transmitted, transcribed, stored in a retrieval system, or translated into any computer language, in any form or by any means, electronic, mechanical, magnetic, optical, chemical, manual, or otherwise, without prior written permission of IBM Corporation. IBM Corporation grants you limited permission to make hardcopy or other reproductions of any machine-readable documentation for your own use, provided that each such reproduction shall carry the IBM Corporation copyright notice. No other rights under copyright are granted without prior written permission of IBM Corporation. The document is not intended for production and is furnished “as is” without warranty of any kind. All warranties on this document are hereby disclaimed, including the warranties of merchantability and fitness for a particular purpose.

U.S. Government Users Restricted Rights—Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corporation.

TrademarksIBM, the IBM logo, Tivoli, the Tivoli logo, and SecureWay are trademarks or registered trademarks of International Business Machines Corporation or Tivoli Systems Inc. in the United States, other countries, or both.

Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.

Lotus is a registered trademark of Lotus Development Corporation.

Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both.

UNIX is a registered trademark of The Open Group in the United States and other countries.

Other company, product, and service names may be trademarks or service marks of others.Notices

References in this publication to Tivoli Systems or IBM products, programs, or services do not imply that they will be available in all countries in which Tivoli Systems or IBM operates. Any reference to these products, programs, or services is not intended to imply that only Tivoli Systems or IBM products, programs, or services can be used. Subject to valid intellectual property or other legally protectable right of Tivoli Systems or IBM, any functionally equivalent product, program, or service can be used instead of the referenced product, program, or service. The evaluation and verification of operation in conjunction with other products, except those expressly designated by Tivoli Systems or IBM, are the responsibility of the user. Tivoli Systems or IBM may have patents or pending patent applications covering subject matter in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to the IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, New York 10504-1785, U.S.A.

Contents

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vWho Should Read This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vWhat This Guide Contains. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vPublications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi

Tivoli SecureWay Policy Director WebSEAL Library . . . . . . . . . . . . . . . . . . . . . . . viTivoli SecureWay Policy Director Base Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . viIBM SecureWay Directory Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viiiTivoli SecureWay Policy Director Web Portal Manager . . . . . . . . . . . . . . . . . . . viiiAccessing Publications Online . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viiiOrdering Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ixProviding Feedback about Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

Contacting Customer Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ixConventions Used in This Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x

Typeface Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xOperating System-dependent Variables and Paths . . . . . . . . . . . . . . . . . . . . . . . . . . x

Chapter 1. Capacity Planning. . . . . . . . . . . . . . . . . . . . . . . .1Capacity Planning Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2Understanding Network Topology Choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Servers in a WebSEAL Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3WebSEAL Network Topology Choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4Physical Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Identifying Server Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Transactions in a WebSEAL Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Defining Server Transaction Throughput Requirements . . . . . . . . . . . . . . . . . . . . . . . . 8Basing Estimates on Empirical Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Basing Estimates on Registered Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Reauthentication Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10WebSEAL User Cache Size and Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Choosing Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Memory and Disk Storage Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Tivoli SecureWay Policy Director: Capacity Planning Guide iii

Obtaining Measurements/Throughput Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Modifying Transaction Types to Match Measurement Reports . . . . . . . . . . . . . . . . 13Scaling for Hardware Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Operating System Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Scaling for CPU Utilizations Less Than 100% . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Scaling for Differences in Page Sizes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Scaling for Page Size and Imbedded Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Scaling for Physical Network Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Calculating the Required Number of Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Increasing the Number of Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Making Network Topology Choices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Capacity Planning Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Understanding Network Topology Choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Identifying Server Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Defining Server Transaction Throughput Requirements . . . . . . . . . . . . . . . . . . . . . 21Choosing Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Obtaining Measurements/Throughput Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Calculate the Required Number of Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Make Network Topology Choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

iv

Preface

Tivoli® SecureWay® Policy Director is the base software that is required to run applications in the Tivoli Policy Director product suite. It enables the integration of Tivoli SecureWay Policy Director applications that provide a wide range of authorization and management solutions.

Tivoli SecureWay Policy Director WebSEAL is an application in the Tivoli SecureWay Policy Director product suite. WebSEAL is a high-performance, multi-threaded Web server that applies fine-grained security policy to the protected Web object space. It can provide single sign-on solutions and incorporate backend Web application server resources into its security policy.

The Tivoli SecureWay Policy Director Capacity Planning Guide assists planners in determining the number of WebSEAL, LDAP, and backend Web servers needed to achieve a required workload.

Who Should Read This GuideThis guide is for system administrators or installation planners responsible for planning the deployment of Tivoli SecureWay Policy Director and WebSEAL.

What This Guide ContainsThis guide contains the following main sections:

■ “Capacity Planning Process” on page 2

■ “Understanding Network Topology Choices” on page 3

■ “Identifying Server Transactions” on page 6

■ “Defining Server Transaction Throughput Requirements” on page 8

■ “Choosing Hardware” on page 11

■ “Obtaining Measurements/Throughput Rates” on page 12

■ “Calculating the Required Number of Machines” on page 18

Tivoli SecureWay Policy Director: Capacity Planning Guide v

Preface

■ “Making Network Topology Choices” on page 19

■ “Capacity Planning Example” on page 19

PublicationsThis section lists publications in the Tivoli SecureWay Policy Director library and any other related documents. It also describes how to access Tivoli publications online, how to order Tivoli publications, and how to make comments on Tivoli publications.

Tivoli SecureWay Policy Director WebSEAL Library

The following documents are available in the /doc directory on the Tivoli SecureWay Policy Director WebSEAL, Version 3.8 CD and on the Tivoli Customer Support Web site:

■ Tivoli SecureWay Policy Director WebSEAL Installation Guide, GC32-0683

Explains how to install, configure, and upgrade Tivoli SecureWay Policy Director WebSEAL.

■ Tivoli SecureWay Policy Director WebSEAL Administration Guide, GC32-0684

Provides a comprehensive set of procedures and reference information for managing the resources of your secure Web domain. This guide also provides you with valuable background and conceptual information for a wide range of WebSEAL functionality.

Tivoli SecureWay Policy Director Base Library

The following documents are available in the /doc directory on the Tivoli SecureWay Policy Director Base CD for your particular platform and on the Tivoli Customer Support Web site. For additional sources of information about Tivoli SecureWay Policy Director and related topics, including LDAP and public key infrastructures, see the following Web site:

http://www.ibm.com/redbooks

■ Tivoli SecureWay Policy Director Release Notes

vi

Preface

Provides late-breaking information, such as software limitations, workarounds, and patch availability.

■ Tivoli SecureWay Policy Director Base Installation Guide, GC32-0735

Explains how to install, configure, and upgrade Tivoli SecureWay Policy Director software.

■ Tivoli SecureWay Policy Director Base Administration Guide, GC32-0680

Describes the concepts and procedures for using Tivoli SecureWay Policy Director services. Provides instructions for performing tasks from the pdadmin command line interface.

The following supplemental documentation is available on the Tivoli Customer Support Web site only. For information about how to access this Web site, see “Accessing Publications Online” on page viii.

■ Tivoli SecureWay Policy Director Base Administration API Developer’s Reference

Provides reference material about using the administration API to enable an application to perform Tivoli SecureWay Policy Director administration tasks. This document describes both Java™ and C implementations of the administration API.

■ Tivoli SecureWay Policy Director Base Authorization ADK Developer’s Reference

Provides reference material about using the development tools and authorization API to enable an application to use Tivoli SecureWay Policy Director security. This document describes both Java and C implementations of the authorization API.

■ Tivoli SecureWay Policy Director Base Performance Tuning Guide, GC32-0812

Provides performance tuning information for an environment consisting of Tivoli SecureWay Policy Director and WebSEAL components.

Tivoli SecureWay Policy Director: Capacity Planning Guide vii

Preface

IBM SecureWay Directory Library

IBM SecureWay Directory, Version 3.2.1, is shipped on the Tivoli SecureWay Policy Director Base CD for your particular platform. If you plan to install the IBM SecureWay Directory server, the following document is available in the /doc/Directory/install_config_guide/platform directory:

■ IBM SecureWay Directory Installation and Configuration Guide (aparent.htm)

Provides installation, configuration, and migration information for IBM SecureWay Directory components on AIX, Solaris, and Windows operating systems.

For more information about IBM SecureWay Directory, see the following Web site:

http://www.software.ibm.com/network/directory/library/

Tivoli SecureWay Policy Director Web Portal Manager

If you received a Tivoli SecureWay Policy Director Web Portal Manager, Verson 3.8 CD with your particular Tivoli SecureWay Policy Director solution, you can install the Web portal manager interface. This Web-based interface enables you to perform Tivoli SecureWay Policy Director administration tasks. The Web portal manager replaces the management console previously shipped with Tivoli SecureWay Policy Director.

The following document is located in the /doc directory:

■ Tivoli SecureWay Policy Director Web Portal Manager Administration Guide, GC32-0736

Provides information about installing the Web portal manager and administering Tivoli SecureWay Policy Director servers through its use.

Accessing Publications Online

You can access many Tivoli publications online at the Tivoli Customer Support Web site:

http://www.tivoli.com/support/documents/

viii

Preface

These publications are available in PDF or HTML format, or both. Translated documents are also available for some products.

To access most of the documentation, you need an ID and password. If necessary, you can obtain these from the following Web site:

http://www.tivoli.com/support/getting/

Ordering Publications

You can order many Tivoli publications online at the following Web site:

http://www.ibm.com/shop/publications/order

You can also order by telephone by calling one of these numbers:

■ In the United States: 800-879-2755

■ In Canada: 800-426-4968

■ In other countries, for a list of telephone numbers, see the following Web site:

http://www.tivoli.com/inside/store/lit_order.html

Providing Feedback about Publications

We are very interested in hearing about your experience with Tivoli products and documentation, and we welcome your suggestions for improvements. If you have comments or suggestions about our products and documentation, contact us in one of the following ways:

■ Send an e-mail to [email protected].

■ Complete our customer feedback survey at the following Web site:

http://www.tivoli.com/support/survey/

Contacting Customer SupportIf you have a problem with any Tivoli product, you can contact Tivoli Customer Support. See the Tivoli Customer Support Handbook at the following Web site:

http://www.tivoli.com/support/handbook/

Tivoli SecureWay Policy Director: Capacity Planning Guide ix

Preface

The handbook provides information about how to contact Tivoli Customer Support, depending on the severity of your problem, and the following information:

■ Registration and eligibility

■ Telephone numbers and e-mail addresses, depending on the country you are in

■ What information you should gather before contacting support

Conventions Used in This BookThis book uses several conventions for special terms and actions and operating system-dependent commands and paths.

Typeface Conventions

The following typeface conventions are used in this book:

Bold Lowercase and mixed-case commands, command options, and flags that appear within text appear like this, in bold type.

Graphical user interface elements (except for titles of windows and dialogs) and names of keys also appear like this, in bold type.

Italic Variables, values you must provide, new terms, and words and phrases that are emphasized appear like this, in italic type.

Monospace

Commands, command options, and flags that appear on a separate line, code examples, output, and message text appear like this, in monospace type.

Names of files and directories, text strings you must type, when they appear within text, names of Java methods and classes, and HTML and XML tags also appear like this, in monospace type.

Operating System-dependent Variables and Paths

This book uses the UNIX convention for specifying environment variables and for directory notation.

x

Preface

When using the Windows command line, replace $variable with %variable% for environment variables and replace each forward slash (/) with a backslash (\) in directory paths.

Note: If you are using the bash shell on a Windows system, you can use the UNIX conventions.

Tivoli SecureWay Policy Director: Capacity Planning Guide xi

Preface

xii

Chapter 1.Capacity Planning

Capacity planning is the process of assessing system requirements and ensuring that your Tivoli SecureWay Policy Director environment has adequate resources to service requests at an acceptable rate.

This guide is intended to cover capacity planning of Tivoli SecureWay Policy Director WebSEAL and related servers. However, 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 Tivoli SecureWay Policy Director 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 Server Transactions

■ Defining Server Transaction Throughput Requirements

■ Choosing Hardware

■ Obtaining Measurements/Throughput Rates

■ Calculating the Required Number of Machines

■ Making Network Topology Choices

■ Capacity Planning Example

Tivoli SecureWay Policy Director: Capacity Planning Guide 1

Capacity Planning

Capacity Planning Process The capacity planning process begins with a communication system that supports several 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 server is to handle and to map the workload to individual server 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 server. Lastly, make network topology choices.

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 varies depending on many factors, including experience level, 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.

2

Capacity Planning

Understanding Network Topology ChoicesIn a typical communication system, there are several choices for network topology. In this context, network topology refers to the distribution of servers among multiple machines and the network connections that result. To understand the network topology, you must identify the servers in the system and gather information about each server. For example, gather the following information:

■ Determine the function that each server in the communication system performs and the options it supports. The purpose of each server can provide a natural choice for network topology, but there also are several options to consider.

■ For each server, determine the other servers with which it communicates.

■ Determine the choices for combining and separating servers. Typically, the choice is flexible. Each server can run on a separate machine or be combined with other servers.

■ Determine whether servers can be replicated or not. A server might not support replication, yet still can be replicated. In this case, replication is a manual process.

Servers in a WebSEAL EnvironmentIn a WebSEAL environment, several servers handle workload. Table 1 lists these servers along with their support for replication. If you plan to deploy additional servers in the same environment, you also must consider workload for these servers.

Table 1. Servers in a WebSEAL environment.

Server Replication Support

WebSEAL (PDWeb) Yes, through the use of a network load balancer, such as the IBM eNetwork Dispatcher

Lightweight Directory Access Protocol (LDAP)

Yes, Tivoli SecureWay Policy Director can load balance between multiple LDAP servers


Capacity Planning

WebSEAL Network Topology ChoicesFollowing are some basic WebSEAL network topologies:

Single machine: all servers combined

■ WebSEAL

■ Management server

■ LDAP

Two machines: WebSEAL and LDAP on separate machines

■ WebSEAL machine

• WebSEAL

• Management server

■ LDAP machine

Three machines: WebSEAL, LDAP, and backend (junctioned) Web server on separate machines

Backend Web servers Might require manual replication. Tivoli SecureWay Policy Director can load balance between multiple backend servers.

Table 1. Servers in a WebSEAL environment.

Server Replication Support

4

Capacity Planning

■ WebSEAL machine

• WebSEAL

• Management server

■ LDAP machine

■ Backend Web server

Other topologies exist by separating and replicating servers. For example, you can separate the management server 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 servers and possibly backend Web servers to multiple machines. WebSEAL supports load balancing and failover between multiple LDAP and backend Web servers.

Physical NetworksAnother 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 server 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 solve the problem. Higher line speeds are another option.

For capacity planning purposes, treat the network like a special type of server. It handles load. If the choices for physical networks are known, treat each physical network as a separate server. Otherwise, think of the entire network as one big server and split it into multiple physical


Capacity Planning

networks if necessary. The physical network supports replication in the sense that is supports sub-netting and multiple IP addresses per machine.

Identifying Server TransactionsAfter you have identified all servers 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 level transactions with each system level transaction broken down into server level transactions on one or more servers in the system. This step in the capacity planning process seeks to identify all the transactions that each server 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 Server Transaction Throughput Requirements” on page 8.

For example, consider a WebSEAL environment in which a high-level transaction consists of an authenticated Web page access. Assume that page access requires Secure Sockets Layer (SSL), uses LDAP authentication, averages about 5 KB in size, and flows through a WebSEAL TCP junction. This work request visits the WebSEAL server, the LDAP server, a backend Web server, and the physical network.

The resulting server transactions are as follows:

Table 2. Server transactions example.

Server Transaction

WebSEAL SSL authenticated Web page access to a TCP junctioned backend

LDAP WebSEAL-driven authentication

Backend Web server TCP Web page access

Physical network Approximately 10 KB of traffic, including a small overhead for LDAP server communication

6

Capacity Planning

Transactions in a WebSEAL EnvironmentThe primary, high-level transaction in a WebSEAL environment is access to a Web page. There are several 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 environment is the administrative update, such as creating, deleting, listing, and modifying users or ACL entries. Following are some of the parameters that are involved in defining a transaction in a WebSEAL environment:

■ WebSEAL server

• 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 Tivoli SecureWay Policy Director cache or not

– If authenticated, failed login or not

– Logout (pkmslogout page request) or not

– Junctioned or not junctioned to a backend Web server

– If junctioned, TCP or SSL junction type

– If junctioned, backend requires authentication or not

– Web page size

• Administrative

– Create, delete, list, or modify a user

– Create, delete, list, or modify an ACL

■ LDAP server

• Authentication

– User from LDAP cache, DB2 cache, or disk (non-cached)

– Failed authentication or not


Capacity Planning

– If failed authentication, why? User not found or invalid password

– Registry size (number of users)

• Administrative

– 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)

– Frequency of propagation (immediate or delayed)

– Registry size (number of users)

■ Backend Web server

• TCP or SSL

• Authenticated, post-authenticated, not authenticated

• Web page size

■ Physical network

• Number of bytes in each transaction

• Line speed

Defining Server Transaction Throughput Requirements

The next step in the capacity planning process is to define the server transaction throughput requirements for each transaction on each server. This is when the frequency of each server transaction is defined. To start, define the system level transaction throughputs and then map them to server level transactions for each of the servers involved.

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 environments. This is not

8

Capacity Planning

always possible, so other methods, or a combination of methods, for estimating transaction throughputs are necessary.

Basing Estimates on Empirical DataFollowing are ways to gather empirical data. Take IP packet traces and extract the types of transactions and their frequencies over time. Ensure that server 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 environments.

Basing Estimates on Registered UsersAnother 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 given time period. Along with this, there is an idea of what an average user does in terms of putting load on the system. For example, the percentage of users in any given time period is the authentication rate. The authentication rate times the load applied by an average user gives the throughput for the average 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 / 60minutes in an hour / 60 seconds in a minute = 4.63auths/sec

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. However, when using this formula as an estimation tool, you also must consider a variety of influencing factors,


Capacity Planning

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 10.

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 previous example, it takes 5 days to authenticate every user as calculated in the following formula:

2,000,000 users / 4.63 users authenticating per second = 431965 seconds to authenticate all users or 5 days

A quick way to derive 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 active 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 given day. Perhaps the rate derived 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 active user and 10 minutes for inactive 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.

10

Capacity Planning

Taking the 4.63 auths/sec example and the WebSEAL default cache size and timeout values, 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 active use timeout, so it limits the user session to 15 minutes before having 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 values, 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 4.63 auths/sec authentication rate is used. The cache size that gives 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 server. If the authentication load is spread among multiple WebSEAL servers, be sure to use the effective rate that is applied to each server when calculating push out times from WebSEAL’s user cache. For example, the overall 4.63 auths/sec authentication rate becomes 2.32 auths/sec when load balancing between two WebSEAL servers. Use the 2.32 auths/sec when calculating cache sizes and user session times.

Choosing HardwareThe choice of hardware might or might not be flexible. You might have a requirement for a specific type of machine or network or you might need to make the most cost-effective choice from a range of hardware. In either case, you must choose hardware.

To evaluate the cost of different hardware choices, the process can be done iteratively with a different hardware specification each time.

From a machine perspective, 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 environment. For workload capacity planning


Capacity Planning

purposes, each server is assumed to have enough RAM and disk space to run efficiently.

From a physical network perspective, the choices are defined in terms of type of network, such as Ethernet or fiber optics, line speed, and network adapter card manufacturer.

The following sections describe capacity planning issues related to hardware.

Memory and Disk Storage PlanningRelated to capacity planning is planning for memory and disk storage requirements. For each server in the system, consult the server 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 environment. WebSEAL, LDAP, and DB2 have caches for holding authenticated users. WebSEAL has a cache for holding SSL sessions. WebSEAL has 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 LDAP holds its data in DB2 tables. The disk space requirements are directly related to registry size.

Obtaining Measurements/Throughput RatesIn this step of the capacity planning process, you must match all identified server 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 server until throughput levels off and response times become too long.

12

Capacity Planning

Server throughput measurements can come from several sources, including the provider of the server 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 environment in which the communication system is to be deployed.

One item to observe 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, view information about IBM RS/6000s if you plan to deploy RS/6000s. Also attempt to match similar CPU speeds, operating systems, and operating system levels.

If measurement reports are not available 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 environments do not match available measurements.

Modifying Transaction Types to Match Measurement Reports

If there is no comparable measurement for an identified server transaction type, it is recommended that you break the identified server transactions down into multiple lower level transactions or combine them with others to form a single higher-level 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 DifferencesOne method for bridging hardware differences is to use published benchmarks, available from the following Web site:


Capacity Planning

http://www.spec.org

The Standard Performance Evaluation Corporation (SPEC) provides 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, or SPECint_rate2000.

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 formachine 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 relative 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

14

Capacity Planning

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 provided, less than maximum throughput might be indicated by less than 100% CPU utilization on the server being measured. It is typical and good when load-generating and non-measured servers run at less than 100% CPU utilization, but the server being measured should be close to 100% utilized.

When data is provided on throughput as load increases, an indication of less than maximum throughput is a lack of leveling off in the throughput. If response times are provided 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 achieved, but it requires knowledge of the CPU utilization. It also results in a larger margin of error, since software systems do not always behave 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

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 SizesFor the most part, every Web page has a different size. If the size of various Web pages is the only difference among them in terms of the


Capacity Planning

server transaction definition, all the pages can be treated as one average-sized page.

For example, if workload requirements identify an average user session consisting of three 5 KB page accesses, two 10 KB page accesses, and one 15 KB page access, the equivalent page size for capacity planning purposes is 8.3 KB. For this example, the average page size is calculated as follows:

(3 * 5 KB pages + 2 * 10 KB pages + 1 * 15 KB) / 6 total pages = 8.3 KB average 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. Given the throughput for two Web page accesses in which all other server 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 given two points. Because throughput graphs act like the function y=1/x, you must use the inverse 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) to be on the same line, the following equation must be true:

(y - y1) / (x - x1) = (y1 - y2) / (x1 - x2)

Solving for y, we have 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 inverse of throughput, which acts like a line. In the following equation, all y’s have been inverted, so that y represents throughput:

1/y = (x - x1) * (1/y1 - 1/y2) / (x1 - x2) + 1/y1

Solving this for y again, we have the following:

y = 1 / ((x - x1) * (1/y1 - 1/y2) / (x1 - x2) + 1/y1)

In this formula, the variables have the following definitions:

16

Capacity Planning

■ 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

Scaling for Page Size and Imbedded ImagesUse 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. Averaging the size of the Web pages is recommended (as explained in the previous example). Do not treat the entire set of objects as one large Web page access. In other words, average 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 DifferencesWhen 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 servers are capable of achieving. This is because line speed differences do not affect the server’s ability to do work. It can be a concern if the network adapter card makes heavy use of the CPU. However, 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. Alternatively, the physical network’s throughput can be estimated as some percentage of its theoretical rate. For example, a 100 Mbps Ethernet network can easily achieve 7 MB per second rates with file transfer protocol (ftp), which is 70% of the theoretical rate. The physical


Capacity Planning

network capacity tends to be less of a concern since most physical networks achieve high rates of transfer. Even so, it is recommended that you give some consideration to the physical network capacity.

Calculating the Required Number of MachinesAfter you define the transactions and requirements for each server 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 divided by the achievables, or measurements. For example, if the requirements are twice the achievables, the result is two; meaning that two machines are needed to meet the requirements.

The ratios are calculated for each transaction type for a given server, and then added together to get the full story for that server. The calculation is repeated for each server. This includes the physical network, which is treated as a special type of server 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/M3 + . . . + Rn/Mn

Variable definitions in this formula are as follows:

■ Machine factor specifies the portion of or number of machines needed for a given server.

■ n specifies the number of transactions identified for the given server.

■ 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

18

Capacity Planning

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 ChoicesIf the number of machines needed for a server 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 server.

If the ratio for the physical network is greater than one, the throughput exceeds the available bandwidth or line speed. Choose a faster network or divide the communication system into multiple subnets.

If the number of machines needed for a server is less than one, it might be possible to combine it with another server, 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 failover, backup, resource usage, and firewall protection. These factors are beyond the scope of this document.

Capacity Planning ExampleThe following example steps you through the capacity planning process for a fictitious company.

Understanding Network Topology ChoicesAssume that network topology choices have been limited to the following case:

WebSEAL used to protect resources on a backend Web server

WebSEAL is placed in a DMZ connecting Internet users on one physical network to Intranet backend Web servers on another physical network. LDAP is used as the registry and resides on the Intranet for security purposes. All servers support replication.


Capacity Planning

Identifying Server TransactionsAssume that the common parameters that define the Web page access transaction are as follows:

■ Tivoli SecureWay Policy Director connects to the backend Web server using a TCP junction with options that filter the original identity of the user and replace it with one provided by WebSEAL (–B, –U, and –W options). ACLs are defined in WebSEAL to protect backend Web server resources.

■ Authentication is tuned as described in the Tivoli SecureWay Policy Director Base Performance Tuning Guide.

■ The average Web page is 10 KB in size.

Assume that the following high-level transactions are identified:

■ TCP page—A user makes a request for a HTTP (TCP) Web page going through WebSEAL to a backend Web server. 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 server. 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 server. No authentication occurs.

The high level transactions break down to the following server transactions:

20

Capacity Planning

Defining Server 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

Table 3. Server transactions example.

Server Transaction

WebSEAL 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

LDAP Authentication

Backend Web server 10 KB TCP page access, already authenticated (Tivoli SecureWay Policy Director authenticates to backend Web servers infrequently as defined by backend server, infrequent enough to be insignificant)

Internet network 10 KB Web page requests plus SSL, TCP, HTTP, and IP headers

Intranet network 10 KB Web page requests and 200 byte LDAP lookups plus TCP, HTTP, and IP headers


Capacity Planning

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

The following are the throughput requirements by server:

Table 4. Throughput requirements example.

Server Transaction Throughput requirements


15 /sec


5 /sec


45 /sec

LDAP Authentication 5 /sec

Backend Web server 10 KB TCP page access

65 /sec


780 KB/sec


781 KB/sec

22

Capacity Planning

The Internet network throughput requirement is calculated as follows:

(15 TCP pages/sec + 50 SSL pages/sec) * 10 KB/page => 650KB/sec + 20% headers = 780 KB/sec

The Intranet network throughput requirement is calculated as follows:

650 KB/sec Internet requirement + (5 SSL auth/sec) * 200bytes => 651 + 20% headers = 781 KB/sec

Choosing HardwareAssume that the choice for all servers is the Sun Enterprise 450. The E450 is a 4-way 400 Mhz UltraSPARC-II processor machine.

Also assume that the choice for both networks is 100 Mbps Ethernet LANs.

Obtaining Measurements/Throughput RatesAssume that you obtained the following fictitious measurements for the Sun E450 as shown in Table 5:


Capacity Planning

Table 5. Example measurements.

Server TransactionMaximum

throughput measurements

WebSEAL 100 byte TCP page access through a TCP junction

750 /sec

5 KB TCP page access through a TCP junction

700 /sec

10 KB SSL page access through a TCP junction

655 /sec (estimated, see the formula described following this table)


40 /sec


250 /sec

LDAP Authentication 35 /sec

Backend Web server 10 KB TCP page access

750 /sec


7+ MB/sec


7+ MB/sec

24

Capacity Planning

If you compare Table 5 to Table 4 on page 22, you can see that matching measurements exist for all the cases, except the WebSEAL TCP page access. There are typically more mismatches between requirements and measurement than this, but only one case is chosen to simplify the example.

Scale the TCP page size difference as described in the “Scaling for Differences in Page Sizes” on page 15. The estimated throughput for a WebSEAL 10 kilobytes (KB) TCP page access, estimating from the throughput measurements of the 100 bytes and 4 KB cases, is 655 pages/sec as calculated in the following formula:

y = 1 / ((x - x1) * (1/y1 - 1/y2) / (x1 - x2) + 1/y1)y = 1 / ((x - 100) * (1/750 - 1/700) / (100 - 5*1024)+ 1/750)1 / ((10*1024 - 100) * (1/750 - 1/700) / (100 - 5*1024)+ 1/750)= 655

Calculate the Required Number of MachinesTable 6 lists the requirements and measurements together with the identified transactions by server.

Table 6. Transactions, requirements, and measurements example.


Maximum throughput

measurements


15 /sec 655 /sec (estimated)


5 /sec 40 /sec


45 /sec 250 /sec


Capacity Planning

The information in Table 6 is used to calculate the machine factors in Table 7:

LDAP Authentication 5 /sec 35 /sec

Backend Web server

10 KB TCP page access

65 /sec 750 /sec

Internet network

10 KB Web page requests plus SSL, TCP, HTTP, and IP headers

780 KB/sec 7+ megabytes (MB)/sec

Intranet network

10 KB Web page requests and 200 byte LDAP lookups plus TCP, HTTP, and IP headers

781 KB/sec 7+ MB/sec

Table 7. Example of calculating the machine factor.

Server Calculation Machine Factor

Increased by 20%

WebSEAL 15/655 + 5/40 + 45/2500

.33 0.39

LDAP 5/350 .140 .17

Backend Web server

65/7500 .090 .10

Internet network 780/70000 .110 .13

Intranet network 780/70000 .110 .13

Table 6. Transactions, requirements, and measurements example.


Maximum throughput

measurements

26

Capacity Planning

Since all machine factors are less than one, each server utilizes only a portion of a machine given by the scaling factor. In other words, the scaling factor, multiplied by 100, gives the percentage of the machine utilized. In the case of the network, it also provides the estimated network utilization.

Make Network Topology ChoicesSince no machine is fully utilized, you should consider combining machines. If security policies allow it, all servers could reside on the same machine, which would still not be fully utilized.


Capacity Planning

28

Index

Aaverage page size formula 16

Bbandwidth, network 5benchmarks 14books

feedback vionline viordering vi

Ccapacity planning

calculating the required number of machines 18

choosing hardware 11defining server transaction throughput

requirements 8example 19identifying server transactions 6making network topology choices 19obtaining measurements/throughput

rates 12overview 1procedure 2process 2understanding network topology choices

3choices

hardware 11network topology 3, 19network topology (WebSEAL) 4

choosing hardware 11considerations

physical network capacity 18reauthentication 10

CPU, scaling for uses less than 100% 15Customer Support ix

Ddefining server transaction throughput 7, 8differences

operating system 14scaling for hardware 13scaling for physical network 17scaling in page sizes 15

directory names, notation xdisk storage and memory 12

Ee-mail contact ixempirical data, estimating based on 9environment variables, notation xerror, margin of 2estimating

based on empirical data 9based on registered users 9

example, capacity planning 19

Ffactor, machine 18, 25feedback about publications ixformulas

calculating average page size 16estimating maximum throughput 15registered user reauthentication 10required number of machines 18WebSEAL user cache size 11


Ggathering

empirical data 9server information 3

Hhardware

choosing 11scaling for differences 13

IIBM SecureWay Directory 12identifying server transactions 6imbedded images, scaling for 17increasing the number of machines 18IP packet traces 9

LLDAP

IBM SecureWay Directory 12server 3, 5, 6, 7

line speed 5

Mmachine factor 18, 25machines

calculating the required number of 18increasing the number of 18

making network topology choices 19manuals


margin of error 2measurement reports, matching 13measurements, obtaining 12memory and disk storage 12modifying transaction types to match

measurement reports 13

Nnetwork bandwidth 5network topology, choices 3, 19networks, physical 5notation

environment variables xpath names xtypeface x

number of machines, calculating 18

Oonline publications viiioperating system differences 14ordering publications ixoverview, capacity planning 1

Ppage size

calculating average 16scaling for 17scaling for differences 15

path names, notation xphysical networks 5, 17procedure, capacity planning 2process, capacity planning 2publications


30

Rreauthentication considerations 10registered users, estimating 9requirements, defining server transaction

throughput 8

Sscaling for

CPU uses less than 100% 15differences in page sizes 15hardware differences 13imbedded images 17page size 17physical network differences 17

serversgathering information 3identifying transactions 6in a WebSEAL environment 3logging 9

Standard Performance Evaluation Corporation (SPEC) 13

Tthroughputs

defining server transaction 8rates 12

timeouts, WebSEAL 10Tivoli Customer Support ixtopology, network 3, 4transactions

defining server throughput 8identifying server 6in a WebSEAL environment 7

Uunderstanding network topology choices 3user cache size, WebSEAL 10

Vvariables, notation for x

WWeb page access 7WebSEAL environment 7

network topology choices 4servers in 3timeouts 10transactions in 7user cache size 10


32

File Number:

Documents

SecureWay Policy Director Capacity Planning Guidepublib.boulder.ibm.com/tividd/td/SW_30/GC32-0811-00/en_US/PDF/pd38...Tivoli SecureWay Policy Director Capacity Planning Guide ... Tivoli