macromedia
®
Using ClusterCATS
Trademarks
Afterburner, AppletAce, Attain, Attain Enterprise Learning System, Attain Essentials, Attain Objects for Dreamweaver, Authorware,
Authorware Attain, Authorware Interactive Studio, Authorware Star, Authorware Synergy, Backstage, Backstage Designer, Backstage
Desktop Studio, Backstage Enterprise Studio, Backstage Internet Studio, ColdFusion, Design in Motion, Director, Director
Multimedia Studio, Doc Around the Clock, Dreamweaver, Dreamweaver Attain, Drumbeat, Drumbeat 2000, Extreme 3D, Fireworks,
Flash, Fontographer, FreeHand, FreeHand Graphics Studio, Generator, Generator Developer's Studio, Generator Dynamic Graphics
Server, JRun, Knowledge Objects, Knowledge Stream, Knowledge Track, Lingo, Live Effects, Macromedia, Macromedia M Logo &
Design, Macromedia Flash, Macromedia Xres, Macromind, Macromind Action, MAGIC, Mediamaker, Object Authoring, Power
Applets, Priority Access, Roundtrip HTML, Scriptlets, SoundEdit, ShockRave, Shockmachine, Shockwave, Shockwave Remote,
Shockwave Internet Studio, Showcase, Tools to Power Your Ideas, Universal Media, Virtuoso, Web Design 101, Whirlwind and Xtra
are trademarks of Macromedia, Inc. and may be registered in the United States or in other jurisdictions including internationally. Other
product names, logos, designs, titles, words or phrases mentioned within this publication may be trademarks, servicemarks, or
tradenames of Macromedia, Inc. or other entities and may be registered in certain jurisdictions including internationally.
This product includes code licensed from RSA Data Security.
This guide contains links to third-party websites that are not under the control of Macromedia, and Macromedia is not responsible for
the content on any linked site. If you access a third-party website mentioned in this guide, then you do so at your own risk. Macromedia
provides these links only as a convenience, and the inclusion of the link does not imply that Macromedia endorses or accepts any
responsibility for the content on those third-party sites.
Apple Disclaimer
APPLE COMPUTER, INC. MAKES NO WARRANTIES, EITHER EXPRESS OR IMPLIED, REGARDING THE ENCLOSED
COMPUTER SOFTWARE PACKAGE, ITS MERCHANTABILITY OR ITS FITNESS FOR ANY PARTICULAR PURPOSE.
THE EXCLUSION OF IMPLIED WARRANTIES IS NOT PERMITTED BY SOME STATES. THE ABOVE EXCLUSION MAY
NOT APPLY TO YOU. THIS WARRANTY PROVIDES YOU WITH SPECIFIC LEGAL RIGHTS. THERE MAY BE OTHER
RIGHTS THAT YOU MAY HAVE WHICH VARY FROM STATE TO STATE.
Copyright © 1999–2002 Macromedia, Inc. All rights reserved. This manual may not be copied, photocopied, reproduced, translated,
or converted to any electronic or machine-readable form in whole or in part without prior written approval of Macromedia, Inc.
Part Number ZCL2M100
Acknowledgments
Project Management: Stephen M. Gilson
Writing: Stephen M. GIlson
Editing: Linda Adler and Noreen Maher
First Edition: May 2002
Macromedia, Inc.
600 Townsend St.
San Francisco, CA 94103
CONTENTS
ABOUT THIS BOOK . . . . . . . . . . . . . . . . . . . . . . . . . . . VII
Developer resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii
About Macromedia documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Viewing online documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Contacting Macromedia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
CHAPTER 1 Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1
ClusterCATS overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2
ClusterCATS capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2
Detailed overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
ClusterCATS product configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5
ClusterCATS components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
System requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
ClusterCATS Server system requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
ClusterCATS Explorer and Web Explorer system requirements . . . . . . . . . . . . . . . . . . . . .8
CHAPTER 2 Scalability and Availability Overview. . . . . . . . . . . . . . 9
What is scalability?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
Load management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12
Successful scalability implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13
Designing and coding scalable applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13
Avoiding common bottlenecks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16
DNS effects on website performance and availability . . . . . . . . . . . . . . . . . . . . . . . . . . . .17
Load testing your web applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20
What is website availability?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23
Availability and reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23
Common failures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24
Website availability scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25
Failover considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25
Creating scalable and highly available sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28
What is clustering? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28
Hardware-based clustering solutions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29
Software-based clustering solutions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30
Combining hardware and software clustering solutions . . . . . . . . . . . . . . . . . . . . . . . . . .32
CHAPTER 3 Installing ClusterCATS . . . . . . . . . . . . . . . . . . . . . . . . 33
Before you install . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34
Upgrading from a previous version of ClusterCATS. . . . . . . . . . . . . . . . . . . . . . . . . . . . .34
Configuring DNS servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34
Configuring server failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38
Using ClusterCATS dynamic IP addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38
Configuring firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Analyzing web server content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39
Considering domain controllers (Windows NT only). . . . . . . . . . . . . . . . . . . . . . . . . . . .40
Installing ClusterCATS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41
Installing ClusterCATS on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41
Installing ClusterCATS on UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42
After you install . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
CHAPTER 4 Configuring Clusters . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Introduction to ClusterCATS Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48
ClusterCATS Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48
ClusterCATS Explorer (Windows only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48
ClusterCATS Web Explorer (UNIX only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49
ClusterCATS Server Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52
btadmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53
Creating clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54
Creating clusters in Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54
Creating clusters in UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60
Removing clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62
Adding cluster members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63
Adding cluster members in Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63
Adding cluster members in UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64
Removing cluster members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65
Removing cluster members in Windows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65
Removing cluster members in UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65
Server load thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66
Configuring load thresholds in Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Configuring load thresholds on UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69
Session-aware load balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72
Enabling session-aware load balancing on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72
Enabling session-aware load balancing on UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72
Persistent session failover in JRun . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74
Session swapping overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74
Configuring JRun for session swapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74
Configuring ClusterCATS for session swapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74
Using shared files for session swapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75
Using JDBC for session swapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76
Using ColdFusion probes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Configuring ColdFusion probes in Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77
Configuring ColdFusion probes in UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Using JRun probes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .84
Configuring JRun probes in Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .84
Configuring JRun probes in UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88
iv Contents
Load-balancing devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92
Using Cisco LocalDirector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92
Using third-party load-balancing devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .95
Administrator alarm notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .98
Configuring administrator alarm notifications on Windows. . . . . . . . . . . . . . . . . . . . . . .98
Configuring administrator alarm notifications on UNIX . . . . . . . . . . . . . . . . . . . . . . . . .99
Administrator e-mail options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .100
Configuring administration e-mail options on Windows . . . . . . . . . . . . . . . . . . . . . . . .100
Configuring administration e-mail options on UNIX. . . . . . . . . . . . . . . . . . . . . . . . . . .101
Administering security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .103
Configuring authentication on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .103
Configuring authentication on UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .106
CHAPTER 5 Maintaining Cluster Members. . . . . . . . . . . . . . . . . . 109
Understanding ClusterCATS server modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .110
Changing active/passive settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111
Changing active/passive settings in Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111
Changing active/passive settings in UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .112
Changing restricted/unrestricted settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113
Restricting/unrestricting servers in Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113
Restricting/unrestricting servers in UNIX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114
Using maintenance mode (Windows only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .115
Updating a cluster member (Windows only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .118
Resetting cluster members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .120
Resetting cluster members on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .120
Resetting cluster members on UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .120
CHAPTER 6 ClusterCATS Utilities . . . . . . . . . . . . . . . . . . . . . . . . . .121
Using btadmin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122
Using btadmin on Windows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Using btadmin on UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122
Using bt-start-server and bt-stop-server (UNIX only) . . . . . . . . . . . . . . . . . . . . . . . . . . . .125
Using btcfgchk. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .126
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .126
Sample output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .126
btcfgchk DNS errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Using hostinfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .129
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .129
Sample output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .129
Using sniff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .130
Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .130
Sample output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .130
C o n t e n t s v
CHAPTER 7 Optimizing ClusterCATS . . . . . . . . . . . . . . . . . . . . . . .131
ClusterCATS dynamic IP addressing (Windows only) . . . . . . . . . . . . . . . . . . . . . . . . . . . .132
Understanding static and dynamic IP address configurations . . . . . . . . . . . . . . . . . . . . . 132
Benefits of ClusterCATS dynamic IP addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .133
Setting up maintenance IP addresses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .133
Enabling ClusterCATS dynamic IP addressing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .135
Using server failover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .137
Static versus ClusterCATS dynamic IP addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . .137
Windows domain controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .137
Configuring load-balancing metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .138
Overview of metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .138
Load types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .139
Output variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .139
Troubleshooting the load-balancing metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .140
INDEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
vi Contents
ABOUT THIS BOOK
Using ClusterCATS describes how to use ClusterCATS, the clustering technology that
provides load-balancing and failover services to assure high availability for your web
servers.
Contents
• Developer resources.............................................................................................. viii
• About Macromedia documentation........................................................................ ix
• Contacting Macromedia.......................................................................................... x
vii
Developer resources
Macromedia, Inc. is committed to setting the standard for customer support in developer
education, documentation, technical support, and professional services. The
Macromedia website is designed to give you quick access to the entire range of online
resources. The following table shows the locations of these resources.
Resource Description URL
Macromedia
website
Information on
ColdFusion
Macromedia
ColdFusion
Support Center
ColdFusion
Online Forums
Information on
JRun
JRun Support
Center
JRun Online
Fo ru m s
Installation
Support
Training Information about classes, on-site training,
ColdFusion
Developer
Resources
ColdFusion
Reference Desk
General information about Macromedia
products and services
Detailed product information on
ColdFusion and related topics
Professional support programs that
Macromedia offers
Access to experienced ColdFusion
developers through participation in the
Online Forums, where you can post
messages and read replies on many
subjects relating to ColdFusion
Detailed product information on JRun and
related topics.
Professional support programs that
Macromedia offers.
Access to experienced JRun developers
through participation in the Macromedia
Online Forums, where you can post
messages and read replies on many
subjects relating to JRun.
Support for installation-related issues for
all Macromedia products
and online courses offered by Macromedia
All the resources that you need to stay on
the cutting edge of ColdFusion
development, including online discussion
groups, Knowledge Base, technical
papers, and more
Development tips, articles,
documentation, and white papers
http://www.macromedia.com
http://www.macromedia.com/coldfusion
http://www.macromedia.com/support/
coldfusion
http://webforums.macromedia.com/
coldfusion/
http://www.macromedia.com/products/jrun/
JRun Support Center
http://webforums.macromedia.com/jrun
http://www.macromedia.com/support/email/
isupport
http://www.macromedia.com/support/training
http://www.macromedia.com/desdev/
developer/
http://www.macromedia.com/v1/developer/
TechnologyReference/index.cfm
http://www.macromedia.com/
support/jrun
viii About This Book
Resource Description URL
JRun Developer
Resources
Macromedia
Alliance
All of the resources that you need to stay
on the cutting edge of JRun development,
including online discussion groups,
Component Exchange, Resource Library,
technical papers, and more.
Connection with the growing network of
solution providers, application developers,
resellers, and hosting services creating
solutions with ColdFusion
http://www.macromedia.com/desdev/
developer/
http://www.macromedia.com/partners/
About Macromedia documentation
Macromedia documentation is designed to provide support for the complete spectrum of
participants. The print and online versions are organized to let you quickly locate the
information that you need. The Macromedia online documentation is provided in
HTML and Adobe Acrobat formats.
Viewing online documentation
All Macromedia documentation is available online in HTML and Adobe Acrobat
Portable Document Format (PDF) files.
The PDF files are included on the product CDs and are installed in the docs directory,
although they are an optional part of the installation.
About Macromedia documentation ix
Contacting Macromedia
Corporate
headquarters
Technical support Macromedia offers a range of telephone and web-based
Sales Toll Free: 888.939.2545
Macromedia, Inc.
600 Townsend Street
San Francisco, CA 94103
Tel: 415.252.2000
Fax: 415.626.0554
Web: http://www.macromedia.com
support options. Go to http://www.macromedia.com/support
for a complete description of technical support services.
Tel: 617.219.2100
Fax: 61 7.21 9 .210 1
E-mail: sales@macromedia.com
Web: http://www.macromedia.com/store
x About This Book
CHAPTER 1
Before You Begin
ClusterCATS is a web server clustering technology that provides load-balancing and
failover services that assure high availability for your web servers. ClusterCATS lets you
cluster distributed servers into a single, high-performance, highly available environment
of web server resources.
A cluster consists of two or more web servers located on a LAN or across a WAN. Web
servers included in a cluster operate as a single entity to provide rapid and reliable access
to resources on those web servers. A cluster can help your website avoid the consequence
of busy and failed servers — slow networks. With ClusterCATS you can avoid
bandwidth, latency, and congestion problems.
Contents
• ClusterCATS overview.............................................................................................2
• ClusterCATS components .......................................................................................6
• System requirements................................................................................................ 7
1
ClusterCATS overview
The ClusterCATS technology provides robust features for website availability, load
balancing, and failing-over servers.
A website is no longer just a web server. Most websites have moved beyond static HTML
pages on a web server. To generate dynamic content or process transactions, a website
now includes multiple resources — web servers, files, applications, databases, and other
software processes on multiple servers in one or more locations. The move to a more
advanced site, consisting of multiple resources, often from multiple vendors, introduces a
major problem — overall site availability and performance. More resources, especially
software resources, and more links between them exponentially increase the probability
of failure. Creating a fast, reliable website becomes substantially more challenging.
Macromedia created ClusterCATS, a complete website resource management solution, to
enable service level agreements offering 24x7 availability and optimal response time for
e-commerce, customer self-service, sales automation, customer support, and other critical
business functions. With ClusterCATS, you can build and manage advanced websites,
consisting of multiple resources spanning multiple servers, in one or more locations.
ClusterCATS builds and manages clusters. A cluster is a group of website resources,
including web servers, files, applications, databases, and even the network, that act in
unison, providing reliable and rapid user access. These resources can be clustered in a
single building, distributed in a local area network (LAN), or distributed in a wide-area
network (WAN) in multiple locations across the world. A cluster intelligently detects and
transparently shields users from the following critical problems:
• Failed and busy servers
• Failed and busy applications and databases
• Slow networks caused by congestion, latency, and bandwidth problems
ClusterCATS capabilities
ClusterCATS delivers critical capabilities required by advanced websites today. These
capabilities produce important benefits in the areas of website performance, availability,
manageability, and scalability.
User response time is accelerated with ClusterCATS application and server load
management.
ClusterCATS consists of server and client components. The ClusterCATS Server runs as
a Windows service and ISAPI filter, NSAPI plug-in, or Apache module. ClusterCATS
Explorer is the client-based management application used to build and manage clusters.
Operating in conjunction with an administrative agent on each ClusterCATS Server,
ClusterCATS Explorer provides all the required tools for centrally managing one or more
clusters from any location.
You can also configure ClusterCATS software to enhance simple web server
load-balancing products, such as Cisco’s special-purpose LocalDirector hardware device.
2 Chapter 1 Before You Begin
The following table introduces the ClusterCATS capabilities:
Fea ture De scrip tion
Application and server
load management
Server failover Provides seamless failover of a web server because of a
Session state
management
Application monitor You can configure ClusterCATS to monitor the JRun/ColdFusion
Distributed operations Exploits a distributed operations model, eliminating traffic
Centralized
management
Allows administrators to configure server load thresholds to
provide optimum user response time in JRun/ColdFusion
applications. ClusterCATS Server load management protects
users from overloaded servers.
hardware, software, or network connection to another member in
the cluster. ClusterCATS shields users from unplanned or
planned server failures.
Allows session state to be maintained across your website using
a unique method that eliminates the source IP address server
overload problems caused by proxy users. ClusterCATS
application state management ensures users are not redirected
away from a server while maintaining state.
server or a JRun/ColdFusion application, and restart the server or
application if a failure occurs.
bottlenecks and maximizing performance and availability. All
servers share knowledge of application or web server
performance, and server availability. Each server can respond
directly to a request or redirect a request to a faster server.
Provides a central console to manage and configure all web
servers in your cluster. ClusterCATS Explorer provides both
high-level and detailed views of the status of one or more
websites and all the resources within a website.
Detailed overview
Application and server load management
ClusterCATS improves user response time by managing application load and web server
load across multiple servers.
You establish load management policy through two administrator-defined response time
thresholds. You configure these for each server. One threshold sets the level at which load
management is activated. If this level of activity is reached, ClusterCATS gradually
redirects a percentage of new server requests to the least-loaded server.
The other threshold defines the peak, or maximum, load level. This is defined as the load
level that should not be reached on that server. If this threshold is attained, an alarm is
sent and requests is redirected.
ClusterCATS overview 3
Session state management and failover
For some applications, it is important that a user session is completed on one server.
ClusterCATS offers a session state management option that ensures that the same web
server services requests from a user. When enabled, this option sends the user to the
best-performing server. The user session then remains on that server until completion.
ClusterCATS defines a new session for the following:
• A user comes from a different domain
• A user enters a new URL
• A user employs a bookmark
This approach has distinct advantages over other methods, such as using a source IP
address to define a user session. The ClusterCATS definition of a session is particularly
beneficial if many visitors come from a large proxy server (for example, America Online).
In that scenario, web servers could easily become overloaded.
Should user state be lost completely due to a resource failure, ClusterCATS provides
graceful state failover. This capability automatically displays an administrator-defined
URL for a custom HTML page or JRun page upon resource failure. This page can be
designed to apologize for the failure and, if replicated resources are available, direct the
user to restart the application at the beginning via a specific URL.
Distributed operations
ClusterCATS uses a distributed operations model, eliminating traffic bottlenecks and
maximizing performance. While other hardware and software load-balancing solutions
force all user requests and, typically, all responses through a single special-purpose
network device or server, each ClusterCATS Server can receive a request, respond to a
request, manage traffic load, and support failover. Unlike hardware load-balancing
solutions, ClusterCATS performance is not throttled by network media limitations and
ClusterCATS is network media independent. Consequently, performance scales linearly
as servers and resources are added.
Centralized management
ClusterCATS Explorer, operating in conjunction with an administrative agent on each
ClusterCATS Server, provides all the required tools for building and managing a website
from any location, whether it be an operations center, hotel, or home.
ClusterCATS Explorer features a familiar Windows Explorer-like user interface and
provides both detailed and high-level status views of one or more websites and all
resources within a website.
ClusterCATS Explorer views include:
• Simplifies user interface for the configuration tasks of building a website, including
adding and removing resources, setting load thresholds, selecting alarms, designating
administrators, configuring replication, and state management capabilities
• Real-time graphs of the actual application or HTTP server load and load thresholds
4 Chapter 1 Before You Begin
ClusterCATS product configurations
ClusterCATS includes a comprehensive core set of features and offers several add-on
options for extending its capabilities. All ClusterCATS configurations include:
• Macromedia Enterprise Server (ColdFusion and JRun) load manager
• Configurable load thresholds
• Real-time load monitor
• Session state management (server level)
• HTTP server monitor and auto-restart
• Real-time web server availability monitor
• Web server failover option
• Web server restriction
• Macromedia Enterprise Server monitor and auto-restart
• Macromedia Enterprise Server application monitor and auto-restart
• Administrator authentication
• Alarms
• Daily reports
ClusterCATS overview 5
ClusterCATS components
ClusterCATS consists of these primary components:
• Server Resides on each computer in a cluster. It communicates with the web server
and other ClusterCATS Servers. For more information, see “ClusterCATS Server” on
page 48.
• Server Administrator (Windows only) or btadmin Lets you perform server-specific
administration tasks through a graphical interface. For UNIX-based administration,
use the scriptable btadmin utility, which is also available for Windows users. For more
information, see “ClusterCATS Server Administrator” on page 52 and “Using
btadmin” on page 122.
• ClusterCATS Explorer and Web Explorer Graphical utilities for creating and
managing clusters in Windows and UNIX environments, respectively. For more
information, see “ClusterCATS Explorer (Windows only)” on page 48 and
“ClusterCATS Web Explorer (UNIX only)” on page 49.
The following table shows which components ClusterCATS installs on each platform:
Windows Installation UNIX Installation
ClusterCATS Server ClusterCATS Server
btadmin and ClusterCATS Server
Administrator
ClusterCATS Explorer ClusterCATS Web Explorer (Note: You can access
btadmin (Note: You can administer a UNIX cluster
with the ClusterCATS Server Administrator from a
Windows computer outside the cluster.)
this from a Windows or UNIX computer.)
You must run the installation program on each server that will be part of your cluster and
on the Windows computer (NT, 2000, .NET Server, 98, or 95) from which you will use
ClusterCATS Explorer to administer the cluster. Even if your clusters run on Solaris or
Linux platforms, obtain a Windows computer for running ClusterCATS Explorer. If you
cannot, use the ClusterCATS Web Explorer in conjunction with the included server
utilities to administer your clusters.
6 Chapter 1 Before You Begin
System requirements
This section describes the platforms on which the ClusterCATS components run and
their minimum system requirements.
ClusterCATS Server system requirements
You must install the ClusterCATS Server component on each server in your cluster.
Ensure that your server meets the minimum system requirements for your platform.
Windows system requirements for ClusterCATS Server
• Intel Pentium 200 Mhz or greater CPU
• 100 MB of free disk space
• 128 MB of RAM
• Windows NT (with SP 4 or greater), Windows 2000, or Windows .NET Server
• Internet Information Server or greater; Netscape Enterprise Server v3.5.1 or greater
• Administrative privileges on each server
• A unique IP address assigned to each web server
• Correct DNS entries and configurations (see “Configuring DNS servers” on page 34)
Note: ClusterCATS Server does not run on Windows 98 or Windows 95.
Sun Solaris system requirements for ClusterCATS Server
• Sun SPARC workstation
• 100 MB of free disk space
• 128 MB of RAM (more recommended)
• Solaris operating system v2.51 or greater with Patch 103582-18 or higher
• Netscape Enterprise Server v3.5.1 or greater or Apache Web Server v1.3.6 or greater
• Administrative root privileges on each server
• A unique IP address assigned to each web server
• Correct DNS entries and configurations (see “Configuring DNS servers” on page 34)
Linux system requirements for ClusterCATS Server
• Intel Pentium 200 Mhz or greater
• 100 MB of free disk space
• 128 MB of RAM (more recommended)
• Red Hat operating system v6.0 or greater
• Apache Web Server v1.3.6 or greater
• Administrative root privileges on each server
• A unique IP address assigned to each web server
• Correct DNS entries and configurations (see “Configuring DNS servers” on page 34)
System requirements 7
ClusterCATS Explorer and Web Explorer system requirements
You can install the ClusterCATS Explorer or Web Explorer component on a computer
outside the cluster, so you can administer the cluster from a central location. Ensure the
computer on which you install one of these components meets the minimum system
requirements.
System requirements for the Windows-based Explorer
The Windows-based ClusterCATS Explorer runs from a Windows computer (NT, 2000,
.NET Server, 98, or 95), regardless of the platform on which you install ClusterCATS
Server. Its system requirements are as follows:
• Intel Pentium 200 Mhz or greater CPU
• 100 MB of free disk space
• 64 MB of RAM (128 MB recommended)
• Windows NT Service Pack 5 or greater (if running Windows NT)
• Administrative privileges
System requirements for the ClusterCATS Web Explorer
Use the ClusterCATS Web Explorer if you have a UNIX-only environment. Install the
ClusterCATS Web Explorer program on a UNIX server that meets the following
requirements:
• Sun SPARC workstation
• 75 MB of free disk space
• 128 MB of RAM
• Solaris operating system v2.51 or greater with Patch 103582-18 or higher
• Netscape Enterprise Server v3.5.1 or greater or Apache Web Server v1.3.6 or greater
• Microsoft Internet Explorer 4.0 or greater or Netscape Navigator 3.0 or greater
8 Chapter 1 Before You Begin
CHAPTER 2
Scalability and Availability Overview
This chapter describes the concepts involved in achieving scalable and highly available
web applications.
Contents
• What is scalability? ................................................................................................ 10
• Successful scalability implementations ...................................................................13
• What is website availability?................................................................................... 23
• Creating scalable and highly available sites............................................................. 28
9
What is scalability?
As an administrator, you probably hear about the importance of having web servers that
scale well. But what exactly is scalability? Simply, scalability is a web server’s ability to
maintain a site’s availability, reliability, and performance as the amount of simultaneous
web traffic, or load, hitting the web server increases.
The major issues that affect website scalability include:
• “Performance” on page 10
• “Load management” on page 12
Performance
Performance refers to how efficiently a site responds to browser requests according to
defined benchmarks. You can design, tune, and measure application performance.
Performance can also be affected by many complex factors, including application design
and construction, database connectivity, network capacity and bandwidth, back office
services (such as mail, proxy, and security services), and hardware server resources.
Web application architects and developers must design and code an application with
performance in mind. When the application is built, administrators can tune
performance by setting specific flags and options on the database, the operating system,
and often the application itself to achieve peak performance. Following the construction
and tuning efforts, quality assurance testers should test and measure an application’s
performance prior to deployment to establish acceptable quality benchmarks. If these
efforts are performed well, you can better diagnose whether the website is operating
within established operating parameters, when reviewing the statistics generated by web
server monitoring and logging programs.
Depending on the size and complexity of your web application, it may be able to handle
from ten to thousands of concurrent users. The number of concurrent connections to
your web server(s) ultimately has a direct impact on your site’s performance. Therefore,
your performance objectives must include two dimensions:
• Speed of a single user’s transaction
• Amount of performance degradation related to the increasing number of concurrent
users on your web servers
Thus, you must establish response benchmarks for your site and then achieve the highest
number of concurrent users connected to your site at the response rates. By doing so, you
will be able to determine a rough number of concurrent users for each web server and
then scale your website by adding additional servers.
When your site runs on multiple web servers, you must monitor and manage the traffic
and load across the group of servers. To learn how to do these tasks, see “Hardware
planning” on page 26 and “Creating scalable and highly available sites” on page 28.
10 Chapter 2 Scalability and Availability Overview
Linear scalability
Perfect scalability — excluding cache initializations — is linear. Linear scalability, relative
to load, means that with fixed resources, performance decreases at a constant rate relative
to load increases. Linear scalability, relative to resources, means that with a constant load,
performance improves at a constant rate relative to additional resources.
Caching and resource management overhead affect an application server’s ability to
approach linear scalability. Caching allows processing and resources to be reused,
alleviating the need to reprocess pages or reallocate resources. Disregarding other
influences, efficient caching can result in superior linear application server scalability.
Resource management becomes more complicated as the quantity of resources increases.
The extra overhead for resource management, including resource reuse mechanisms,
reduces the ability of application servers to scale linearly relative to constraining
resources. For example, when a processor is added to a single processor server, the
operating system incurs extra overhead in synchronizing threads and resources across
processors to provide symmetric multiprocessing. Part of the additional processing power
that the second processor provides is used by the operating system to manage the
additional processor, and is not available to help scale the application servers.
It is important to note that application servers can scale relative to resources only when
the resource changes affect the constraining resources. For example, adding processor
resources to an application server that is constrained by network bandwidth would
provide, at best, minor performance improvements. When discussing linear scalability
relative to server resources, you should assume that it is relative to the constraining server
resources.
Understanding linear scalability in relation to your site’s performance is important
because it affects not only your application design and construction, but also indirectly
related concerns, such as capital equipment budgets.
What is scalability? 11
Load management
Load management refers to the method by which simultaneous user requests are
distributed and balanced among multiple servers (Web, JRun, ColdFusion, DBMS, file,
and search servers). Effectively balancing load across your servers ensures that they do not
become overloaded and eventually unavailable.
There are several different methods that you can use to achieve load management:
• Hardware-based solutions
• Software-based solutions, including round-robin Internet DNS or third-party
clustering packages
• Hardware and software combinations
Each option has distinct merits.
Most load-balancing solutions today manage traffic based on IP packet flow. This
approach effectively handles non-application-centric sites. However, to effectively
manage web application traffic, you must implement a mechanism that monitors and
balances load based on specific web application load. ClusterCATS ensures that the JRun
or ColdFusion server, the web server, and other servers on which your applications
depend remain highly available.
For more information on using hardware and software for load balancing, see “Creating
scalable and highly available sites” on page 28.
12 Chapter 2 Scalability and Availability Overview
Successful scalability implementations
Achieving scalable web servers is not a trivial task. There are various solutions from which
to pick, setup and configuration tasks to understand and perform, and many delicate
dependencies between related but heterogeneous technologies. This section describes
some of the major issues affecting successful scalability implementations:
• “Designing and coding scalable applications” on page 13
• “Avoiding common bottlenecks” on page 16
• “DNS effects on website performance and availability” on page 17
• “Load testing your web applications” on page 20
Designing and coding scalable applications
Application architects must create designs that are inherently flexible by relying on open
standards that don’t restrict the application’s construction and implementation to
vendor-specific interfaces and tools. Similarly, web developers that construct the designed
application must be aware that they can significantly impact the application’s scalability
in the way in which they write their code, build their SQL queries, invoke thread
management, access databases, and partition the application.
This section discusses the following topics to consider when designing and building a
web application:
• “Application session and state management” on page 13
• “Database locking and concurrency issues” on page 14
• “Application partitioning” on page 15
Application session and state management
As you create web applications, you will probably create specific variables that you intend
to carry across multiple interactions between a user’s browser and a site’s web server(s).
Using client variables that are stored in a shared state repository, or session variables that
are stored in memory of a specific server, are popular approaches for accomplishing this
task. The latter approach, however, introduces a significant challenge for a website that is
supported by multiple servers. When a user has begun a session and variables are stored
on a specific server, the user must return to that server for the life of the session to
maintain correct state information.
An example that illustrates this concept is an e-commerce application that uses shopping
carts. With this type of application, as a customer accumulates items in a cart, there must
be a mechanism to ensure that the user can see the items as they are added. One approach
is to store these items in session variables on a specific web server. However, if you use this
approach, there must also be a way to ensure that the user always returns to the same
server for the life of the session. ClusterCATS automatically handles this challenge for
you.
Another approach to solving this problem is to store client variables in a back-end
common state repository. This approach enables all web servers in a cluster to access
variables in a common, shared back-end data store, such as a database. However, this
approach can potentially affect your site’s performance.
Successful scalability implementations 13
Web developers must think through the user scenarios in which application session and
state are affected, and engineer appropriate mechanisms to handle them. The most
common ways to handle session data are:
• Client-side options consisting of cookies, hidden fields, a get list, or URL parameters
• Server-side session variables
Note: Storing session data on the server requires that a simple identifier is stored on
the client, such as a cookie.
• An open state repository consisting of a common back-end database or other shared
storage device
Whatever mechanism your architects and engineers use, they must anticipate the
scenarios in which maintaining an application’s state is vital to a good user experience.
See “Session-aware load balancing” on page 72.
Database locking and concurrency issues
Dynamic web applications that allow users to modify a database must ensure appropriate
database concurrency handling. This term refers to how an application manages
concurrent user requests when accessing the same database records. If an application does
not impose a database-locking mechanism on multiple requests to update a record, data
integrity can be compromised in the database — two users could make simultaneous
modifications to a record, but only the second change would take effect.
For example, consider a Human Resources web application on a company intranet. The
HR Generalist adds two new employee records to the HR database by filling out a web
form, because two new employees have been hired. The Generalist enters most of the
vital information into the records, but doesn’t yet have the new employees’ phone
extensions or HMO selections, so leaves those fields blank. Later in the day, the HR
Generalist’s manager, the HR Director, obtains this information from both new hires and
decides to enter it in the database. However, one of the new employees, after speaking
with her husband, decides to change her HMO selection from the basic selection to the
PPO choice. The employee calls the HR Generalist to tell him of the change, and the
Generalist says he will take care of it immediately. Without talking to the HR Director,
the HR Generalist adds the information into the employee records at the same time that
the HR Director is attempting to update the information.
In this scenario, if the application uses an appropriate database concurrency validation
mechanism, the HR Director receives a message indicating that she could not access the
employee record because it was in use, thereby alerting her that someone in her
department was trying to change the record. However, if the application did not use such
a validation mechanism, the HR Director would overwrite the new data that the
Generalist had just entered, resulting in data integrity problems. This example illustrates
the importance of your dynamic web applications handling database concurrency issues
well.
14 Chapter 2 Scalability and Availability Overview
Application partitioning
The way an application is partitioned and deployed dramatically affects its ability to
scale. A key development objective must be to ensure that each partition scales
independently of the others, thereby eliminating application bottlenecks.
Application partitioning refers to the logical and physical deployment of an application’s
three core types of logic, or services — presentation, business, and data access. If you are
familiar with the concept of tiered client/server application development, you already
understand the rationale for developing applications in this way. The following short
review highlights this methodology’s benefits.
An application, regardless of whether it is a web application or a more traditional client/
server application, has three main categories of logic, or services:
• Presentation services — a user interface, by which users interact with the application’s
features. In a traditional client/server application, this logic resides on a client
computer, typically as a proprietary executable file. In a web paradigm, there is no
specific proprietary client software required, other than a browser. Emerging web
technologies can help you leverage powerful client-side processing available through a
browser. These technologies include Enterprise JavaBeans (EJB), scriptlets,
JavaScript, applets, and Dynamic HTML. Well-planned use of these technologies can
reduce unnecessary trips to the server, thereby minimizing performance degradation.
• Business services — the custom business logic and rules that an application uses to
perform calculations and application-specific functions. An example of a business
service is an algorithm that automatically calculates shipping and handling charges
for an order, based on the total cost of the order. In JRun, this logic is contained
within scriptlets and EJBs. In ColdFusion, this logic is contained in ColdFusion
pages. Depending on the nature of the business and how often the business rules
change, business logic can be partitioned to reside on its own server for easier access
that expedites frequent logic modifications, or it can reside in stored procedures on
the database server.
• Data services — the interaction between the application and the database in which
the application stores and manipulates data. The way application manages data
services is directly tied to the application’s performance capability. In short, accessing
a database can be costly and can cause significant performance degradation,
depending on a variety of factors. For example, the types of database drivers used for
connections, the construction of SQL queries, the manner in which database
connections are pooled and maintained, and whether stored procedures are
implemented for frequent database access, all directly impact the application’s
performance.
The way that architects and web developers decide to partition and deploy these core
application services significantly affects the application’s ability to scale. Although your
development efforts may no longer be burdened with developing, distributing,
customizing, and updating proprietary client software for your applications, the
ubiquitous graphical user interface (GUI) — the web browser — presents new interface
issues and challenges. For example, you must ensure that your application’s presentation
remains performance-friendly. It should minimize the number and size of graphic
elements that must be downloaded to the client. Also, because some browsers cannot
Successful scalability implementations 15
cleanly display all technologies, such as cascading style sheets (CSS), Java applets, and
frames, you must carefully evaluate their use in your applications.
Bear in mind these presentation guidelines, to aid your applications’ performance and
user experience, and be sure to plan and test for the lowest common denominator that all
browsers can accommodate.
Often, partitioning business services to a separate business logic application server from
the primary application server, if necessary, can yield better application organization and
easier maintenance. You can maximize your application’s data services by carefully
constructing them and by ensuring that a separate database server (in this case, a separate
computer) is used to increase processor capacity for any database transactions.
These are several of the most important topics you and the developers creating your web
applications should consider early on. In doing so, you ensure that your web applications
are designed and coded with scalability in mind.
Avoiding common bottlenecks
In addition to application design and construction considerations, you must plan to
avoid common bottlenecks that can negatively affect a web application’s performance.
Following are typical bottlenecks that can affect an application’s ability to perform and
scale well:
• Poorly written application logic — inefficient programming is probably the most
common reason applications perform poorly. Instituting industry best practices, such
as coding standards, design reviews, and code walkthroughs, can significantly help to
alleviate this problem.
• Processor capacity — even a well-architected and programmed web application can
perform poorly if the web server’s CPU is unable to provide sufficient processing
power. Ensure that heavy-load, mission-critical applications reside on hardware that
can effectively do the job.
• Memory — insufficient random access memory (RAM) limits the amount of
application data that can be cached. Ensure that the amount of memory installed on
the application server computer is commensurate with the needs of the web
application.
• Server congestion — server congestion refers to all types of servers, not just the web
server. Your application, proxy, search and index, and back-office servers can
periodically experience high volume that indirectly degrades the performance of your
web application. When planning the physical design of the system, investigate
carefully the network topology that will be implemented to ensure that existing
servers are sufficient. If they are not, you may need to add new servers to the topology
to ensure uninterrupted service and performance expectations.
• Firewalls — some dynamic applications that must restrict anonymous access because
they present or share confidential information must pass through a corporate firewall,
which can slow down requests and responses. Ensure that the correct ports are open
on the firewall to ensure valid security authentication and to enable appropriate
client/server communications. (You may be able to open additional secure ports to
accommodate increased traffic.)
16 Chapter 2 Scalability and Availability Overview
• Network connectivity and bandwidth — consider the type of network your
application will run on (LAN/WAN/Internet) and how much traffic it typically
receives. If traffic is consistently heavy, you may need to add additional nodes,
routers, switches, or hubs to the network to handle the increased traffic.
• Databases — database access, while vitally important to your application’s capabilities
and feature set, can be costly in terms of performance and scalability if it is not
engineered efficiently. When creating data sources for accessing your database, use a
native database driver rather than an ODBC driver, if possible, because it will provide
faster access. Similarly, try to reduce the number of individual SQL queries that must
be repetitiously constructed and submitted, by placing common database queries in
stored procedures that reside on the database server. Tune your databases and queries
for maximum efficiency.
DNS effects on website performance and availability
Improper Domain Name System (DNS) setup and configuration on web servers is one of
the most common problems administrators encounter. This section addresses the
following topics:
• “What is DNS?” on page 17
• “DNS effects on site performance and availability” on page 17
• “DNS core elements” on page 18
What is DNS?
DNS is a set of protocols and services on a TCP/IP network that allows network users to
use hierarchical natural language names, rather than computer IP addresses, when
searching for computer hosts (servers) on a network. DNS is used extensively on the
Internet and on private enterprise networks, including LANs and WANs.
The primary capability of DNS is its ability to map host names to IP addresses, and vice
versa. For example, suppose the web server at Macromedia has an IP address of
157.55.100.1. Most people would connect to this server by entering the domain name
(www.macromedia.com), not the less-friendly IP address. Besides being easier to
remember, the name is more reliable, because the numeric address could change for a
variety of reasons, but the name can always be reserved.
DNS effects on site performance and availability
Internet DNS is a powerful and successful mechanism that has enabled huge numbers of
individuals and organizations to create easily locatable websites on the Internet. However,
DNS by itself may not allow your website to perform and scale as it should, thus causing
it to become unavailable and unreliable. Whether you use DNS by itself to load balance
inbound traffic depends largely on the site’s purpose and the amount of concurrent
activity you expect on it. For instance, a low-volume, static site that provides only textual
HTML information can probably be accommodated by round-robin DNS. However, a
high-volume, dynamic, e-commerce site that you anticipate doing lots of volume won’t
perform or scale well if it is only supported by round-robin DNS.
Successful scalability implementations 17
To understand why, let’s look at the e-commerce example. Even if you have planned
ahead and set up multiple servers to support this high-volume site, if you rely only on
DNS, it can only perform two tasks:
• Translate natural language names to server IP address mappings so that users can find
the site
• Distribute load among servers in a rote, sequential distribution manner, if you have
enabled round-robin distribution for multiserver load balancing
However, if a spike in user activity causes servers to overload or fail, round-robin DNS
keeps distributing requests among all servers, even if some are not operating.
In short, Internet DNS is limited in its capabilities, and its round-robin distribution
mechanism does not include intelligence for monitoring, managing, and reacting to
overloaded or failed servers. Consequently, DNS by itself is not a sound load-balancing or
failover solution for your business-critical sites. ClusterCATS compensates for DNS
limitations and lets you create highly available, reliable, scalable web applications.
DNS core elements
The following are core DNS elements that you must be able to configure if your web
applications are to work well with DNS:
• “Zones and domains” on page 18
• “DNS record types, server aliases, and round-robin distribution” on page 19
Zones and domains
A Domain Name System is composed of a distributed database of names. The names in
the DNS database establish a logical tree structure called the domain name space. On the
Internet, the root of the DNS database is managed by the Internet Network Information
Center (InterNIC). The top-level domains were originally assigned organizationally and
by country. Two-letter and three-letter abbreviations are used for countries. Some
abbreviations are reserved for use by organizations — for example, .com, .gov, and .edu
for business, government, and educational organizations, respectively.
A domain is a node on a network and all the nodes below it (subdomains) that are
contained within the DNS database tree structure. Domains and subdomains can be
grouped into zones to allow distributed administration of the name space. More
specifically, a zone is a portion of the DNS name space whose database records exist and
are managed in one physical file. One DNS server may be configured to manage one or
multiple zone files. Each zone is anchored at a specific domain node. You use zones for
breaking up domains across multiple segments to distribute the management of the
domain to multiple groups, and to replicate data more efficiently.
18 Chapter 2 Scalability and Availability Overview
The following figure shows these concepts:
DNS servers store information about the domain name space and are referred to as name
servers. Name servers typically have one or more zones for which they are responsible.
The name server has authority for those zones and is aware of all the other DNS name
servers that are in the same domain.
DNS record types, server aliases, and round-robin distribution
There are three DNS record types that you must define and configure for each web server
in order for ClusterCATS load-balancing and failover technology to work correctly.
These records must be defined and configured on your local and primary DNS servers.
• A Record — contains a host-name-to-IP-address mapping, where the natural
language name is the primary name representing the IP address.
• PTR Record — contains the IP-address-to-host-name mapping. This is the reverse
lookup of the A record, in which, given the IP address, the natural language host
name for the IP address is displayed.
• CNAME Record — short for canonical record. This record contains an alias name
that maps to the primary host name of a web server. For example, you can assign a
server named www1.yourcompany.com an alias of www.yourcompany.com, so that
users never see www1.yourcompany.com, in the event of a server redirection.
To see how all of these records work together, let’s look at a simple example. There are
two web servers, named www1.yourcompany.com and www2.yourcompany.com. You
don’t want users to see the primary host names (A records) for these servers in their
browser; you want them to see only their assigned aliases (CNAME records), when being
redirected.
Successful scalability implementations 19
The DNS entries would look like the following:
:
; Entries for forward-resolution: A-records
www1.yourcompany.com IN A 192.168.0.1
www2.yourcompany.com IN A 192.168.0.2
; Entries for reverse-resolution: PTR-records
192.168.0.1 PTR www1.yourcompany.com
192.168.0.2 PTR www2.yourcompany.com
; Round Robin entries
www.yourcompany.com IN A 192.168.0.1
www.yourcompany.com IN A 192.168.0.2
To ensure that your site lookups and translations occur as intended, you must provide
correct entries in your DNS records, as shown. Also, to enable round-robin DNS
functionality, you must create round-robin entries as shown.
On the Windows platform, you make DNS entries using the Domain Name Service
Manager utility.
On UNIX platforms, you make DNS entries in the name.db file, which is read by the
DNS server’s Berkeley Internet Name Daemon (BIND).
Load testing your web applications
Load testing is the process of defining acceptable benchmarks for your web application’s
performance, and then simulating load and measuring resulting response times and
throughput against the benchmarks. You perform load testing to measure the
application’s ability to scale.
This section discusses the following topics:
• “Reasons to perform load testing” on page 20
• “How to load test your web applications” on page 21
• “Load-testing considerations” on page 22
Reasons to perform load testing
Load testing is important to your website’s success because it lets you test its capacities
before you deploy it, so you can find and fix problems before they are exposed to your
users. Determining your site’s purpose, and the amount of traffic you anticipate, may
affect how you load test it.
Managers of small sites, who don’t expect heavy concurrent loads, might be able to
organize actual users to simultaneously access the site to perform load testing. However,
this is difficult to accomplish well, because it introduces many human variables. In fact,
for larger business-critical systems that expect heavy concurrent load, this type of testing
is not feasible and does not provide satisfactory or realistic results.
A better approach to load testing is to use load simulation software. There are some
excellent software load-testing tools on the market that let you simulate heavy loads
20 Chapter 2 Scalability and Availability Overview
hitting your web server. By using the software in conjunction with your defined
benchmarks and formal test plans, you can confidently determine whether your web
application is ready for deployment.
Another reason to load test is to verify your failover capabilities. Failover ensures that if a
primary server within a cluster of servers stops functioning, subsequent user requests are
directed to another server within the cluster. Failover is addressed in more depth in
“What is website availability?” on page 23. Using load-testing software, you can
essentially force a server redirection by designating a computer as “unavailable” or by
shutting it down.
Note: ClusterCATS uses the HTTP protocol to redirect packets of data from a failed server
to an available server. Therefore, it is important to verify that your load-testing tool can
handle HTTP redirections properly before you initiate load testing.
How to load test your web applications
Before you can load test, you must purchase a load-testing software tool and learn how to
use it.
There is a variety of good load-testing software tools on the market, including Segue’s
SilkPerformer, Mercury Interactive’s LoadRunner, and RSW’s e-LOAD. Each of these
packages provides substantial Web-enabled software-testing solutions that help you
effectively simulate and test load.
After you purchase, install, and learn to use load-testing software, you determine
benchmarks that you want to—or must—achieve for your website, to ensure a good user
experience. Following that, you formalize your testing strategy by designing and
developing written test plans against which you execute your tests.
When the test plans are written and approved, you run the tests. After you do so, you
capture and analyze the load-testing results and report the statistics to the development
team. From there, you’ll need to reach consensus about the most serious problems you
discovered, the necessary changes to make, and the best way to implement the fixes. After
the changes are made and a new build of the application is available, you rerun the tests
to look for performance improvements. Again, you analyze the testing results, and
continue this cycle until the site is operating within the established parameters that you’ve
set. When your team agrees that the site scales well and is operating at peak performance
under heavy stress, you’re ready to deploy the application into a production environment.
Successful scalability implementations 21
Load-testing considerations
Before starting your load testing, consider the following:
• Define benchmarks early — ensure that you understand your website’s performance
and scalability requirements before you start running tests against it. Otherwise, you
won’t know what you’re testing for and the statistics you capture won’t have
significance. Also, remember that the benchmarks you define should be customized
for the current application; don’t simply reuse benchmarks from an earlier site on
which you may have worked. Each web application is distinct in terms of its design,
construction, back-office integration, and user experience requirements.
• Ensure that the test environment mirrors the production environment— create a test
environment that is as close as possible to the production environment in which the
website will be hosted. If you don’t simulate a similar network and bandwidth
scenario, or use the same types of servers, or ensure that the same versions of software
(operating system, service packs, web server, and third-party tools) reside on the test
and production servers, you can’t anticipate problems nor determine why they occur.
The number of possibilities would be too large.
• Minimize distributed environment load testing — load testing in a distributed
environment can be problematic if the network on which you perform load tests
becomes congested, resulting in poor response times. Also, if everyone else in the
organization uses the network for their everyday activities, such as e-mail, source
control, and file management, an increased load on the network will probably cause
significant network degradation for them, and accompanying frustration.
In such a scenario, it might be more effective to physically sit at the server on which
the application resides and perform the tests locally, rather than bring the entire LAN
or WAN to a slow crawl. Also, by testing locally, you can better rule out the network
as the source of the scalability problems. Alternatively, you might be able to configure
a separate subnet on the LAN or WAN that is distinct from the subnet on which
everybody else in your environment uses network services.
You should have a good overview of what scalability implies, the core elements that
compose it, some of the issues that affect successful implementations, and the tasks that
must be performed to verify that your web applications are able to achieve satisfactory
scalability.
The next section describes website availability and reliability concepts and
considerations.
22 Chapter 2 Scalability and Availability Overview
What is website availability?
It is critical to design, develop, test, and deploy web applications so they can scale well
under heavy and ever-increasing load. However, in spite of the best-laid plans and
preparations, servers can fail for seemingly unknown reasons, causing your site to become
unavailable. If and when a server fails or becomes overloaded, you want to ensure that the
failure won’t adversely affect your business by preventing your customers from accessing
and using your web application. If it does, you risk jeopardizing your bottom line with
lost sales and disgruntled customers who will look to your competitors for goods and
services.
This section defines and describes website availability and failover:
• “Availability and reliability” on page 23
• “Common failures” on page 24
• “Website availability scenario” on page 25
• “Failover considerations” on page 25
Availability and reliability
In simple terms, availability and reliability mean that you can access a website by entering
the site’s URL in your browser, and all of its features work as intended. Thus, availability
and reliability refer to the uptime of a website, which is often directly related to the
uptime of the web server and other dependent servers, such as a database server, an
application server, or a file server. For a site to be considered available, all of the servers
that provide its functionality must work.
What is website availability? 23
For JRun and ColdFusion web applications, it is particularly important that the servers
remain as highly available and responsive as the web server and other dependent servers.
JRun and ColdFusion process requests sent to them from the web server. Upon
successfully processing the application logic, JRun and ColdFusion return the results to
the web server, which in turn returns an HTML response to the browser.
Availability and reliability are concerned with keeping the relevant servers that provide
services to your web application available at all times. However, if a server on which your
site depends becomes unavailable, you must have a sound redundancy scheme to make
certain that your site remains available. As your organization moves into an e-business
paradigm, you must plan, design, and implement load-balancing and failover strategies
that guarantee that your servers will remain operational.
If servers employ a good strategy for load balancing and failover, they provide high
availability and reliability to their users. In fact, Internet Service Providers (ISPs) that
host commercial websites and offer 24x7 technical support as a competitive service
differentiator typically specify in written service-level agreements a percentage of time
that they guarantee a website will be available. If the ISP has a sound scalability and
failover strategy in place, this figure is usually in the range of 99% or better.
Common failures
Following are typical types of failures that can negatively impact your web application’s
availability and reliability:
• Hardware failures — while less common than software failures, hardware failures do
occur, and can include crashed hard drives, blown processors, and corrupted network
cards. Diagnosing and fixing these issues can be a lengthy endeavor because of time
spent getting parts and performing labor. If your web application is mission-critical,
you should ensure a sound hardware redundancy strategy to avoid costly downtime.
A sound strategy includes a minimum of two, but preferably three, web servers.
• Software failures — the software failures that most affect a web application involve
the web server’s operating system, the web server software itself, or the web
application software. If the operating system crashes or becomes corrupt, the web
server cannot function properly (or perhaps at all), compromising your web
application’s availability, reliability, and performance. Similarly, if the web server
software crashes or acts erratically, it will probably cause the web server to stop
running. Preparing for software failures is difficult, but if you have mirrored
secondary hardware systems in place to account for failures, you’ll minimize your web
application’s downtime.
• Server failures — other servers on which your web application depends can also fail,
causing downtime or diminished capabilities on your site. For example, for
distributed applications, a proxy server might go down, causing requests for your web
application’s services to go unanswered. Or the database server might crash, making it
impossible for users to submit or retrieve information from your database. Or a mail
server might go down, making it impossible for your users to successfully send mail
to you. Ensure that your organization’s IT architecture includes network monitoring
and notification software that can quickly report on the general health of your
network and alert you about any failed servers.
24 Chapter 2 Scalability and Availability Overview
Website availability scenario
Imagine that you have just built a robust, interactive e-commerce website on which you
plan to sell the most sought-after books and music in the world. You have used Java
scriptlets to build the application, so of course you’ve taken advantage of its many
built-in features, including secure database access, multithreading, and integrated session
management.
Upon finishing the development work and quality assurance testing, you deploy the
website onto one production web server that is hosted within your IT department. The
IT department informs you that it can use its existing Internet connection to make your
site live, avoiding the additional hosting support cost of using an outside vendor.
The site goes live, and it’s an instant success. Orders start pouring in the very first day,
and huge numbers of people log on to browse and buy. Everything seems perfect. Then,
on the second day of business, the load hitting the site is so high, the web server’s
performance slows to a crawl, eventually causing the server to become unavailable.
Suddenly, your tech support lines are ringing off the hook with complaints that users
cannot access your site, causing you to lose significant business.
Although the application provided many useful features and capabilities, customers could
not access them, because the site’s performance degraded to the point that the site
became unavailable. Because the site was deployed on only one server, the incoming
traffic could not be load balanced. Also, without redundant servers in place, the site
could not intelligently load balance increasing traffic nor redirect traffic to other available
servers (no failover).
This simple scenario illustrates how critical adequate scalability, performance, and
failover planning are to any successful web development effort. Servers can become
overloaded or fail at any time, so ensure that your design, development, testing, and
deployment strategies are sound, promote good communication between necessary
departments, and include adequate disaster recovery capabilities.
Failover considerations
The ability to failover unavailable servers to redundant servers is a cornerstone of any
mission-critical application, one that ensures an application’s continuous and reliable
operation. Such disaster planning and recovery can be broken down into these topics:
• “Hardware planning” on page 26
• “Systems monitoring” on page 26
• “Corrective actions” on page 26
Review the following considerations to ensure that you have a sound failover strategy in
place — one that guarantees your website’s availability.
What is website availability? 25
Hardware planning
As indicated in the availability example above, you must acquire all necessary hardware
and configure it before you deploy an application. All websites have different
requirements, feature sets, purposes, audiences, and budgets, and therefore different
needs. However, if your site is a business-critical system that affects your company’s
bottom line, you must ensure an appropriate redundancy strategy by having two or more
redundant systems in place. In fact, Macromedia recommends that you use a minimum
of three servers to support a critical website, so you can take one server offline to perform
update and maintenance tasks while maintaining at least two servers in production at all
times. This scheme provides administrative flexibility and protects your site from
hardware or software failures.
The two predominant redundancy models used today are:
• Primary/backup servers — an example of this model would be an important web
application that receives relatively little traffic, such as an intranet. Typically, this
redundancy model uses an expensive, high-capacity server for the primary server, and
an inexpensive, lower-quality server for the backup server in case the primary server
fails.
• Parallel servers — this is a classic load-balancing/redundancy mode, and is used most
often for business-critical applications. Unlike the primary backup scheme, the
multiple servers in a parallel scheme are considered peers and are grouped as a single
entity to support one or more applications.
You can use identical cloned hardware in your server clusters, or you can mix
hardware sizes and models. Cloned, higher-capacity, higher-end hardware might have
greater up-front hardware costs, but help minimize long-term administration costs.
Conversely, mixing hardware models and capacities might be less expensive in the
short term, but could add administrative costs later on.
If you plan to use a parallel model, using many middle-range servers, rather than
fewer high-end ones, or many inexpensive ones, is recommended. Servers that
provide adequate capacity and are moderately priced can generally accommodate
your needs as well as expensive ones, but at a fraction of the cost.
Systems monitoring
Ensure that your network and the mission-critical sites that reside on its servers are
supported by systems-monitoring software. This type of software actively and
continuously monitors an application’s availability and service levels. These monitoring
programs must be able to not only detect problems, but also route alerts to
administrators for immediate notification of problems.
Corrective actions
The third major failover consideration is the corrective actions that must occur if a failure
causes a server to become unavailable. Generally, if a server goes down and causes your
site to become unavailable, some level of human interaction is usually required to
effectively diagnose and correct the problem.
26 Chapter 2 Scalability and Availability Overview
However, before the analysis and repair can occur, the administrator must be notified.
Whatever failover system you put in place, it should include an automated notification
system that can route alerts through your telecommunications infrastructure (e-mail,
pagers, real time Web-based alerts, and so on) to the appropriate administrator for
prompt attention.
Besides notifying the administrator that a problem has occurred, you also want your
failover solution to automatically redirect traffic intended for the unavailable server to
other available servers until the unavailable server is fixed. This crucial corrective action is
what keeps your website up and available to your users even if one of the servers
supporting it is experiencing problems.
What is website availability? 27
Creating scalable and highly available sites
When you understand the issues of scalability and availability, the next step is to learn the
techniques you can use to achieve scalable and highly available websites.
This section describes the following topics:
• “What is clustering?” on page 28
• “Hardware-based clustering solutions” on page 29
• “Software-based clustering solutions” on page 30
• “Combining hardware and software clustering solutions” on page 32
What is clustering?
Clustering is a technique in which two or more web servers supporting one or more
domains (such as www.yourcompany.com) are grouped as a cluster of servers, to
collectively accommodate increases in load and provide system redundancy.
The following figure shows an example of a server cluster for a website:
Clustering for scalability works by distributing load among servers in the cluster (load
balancing) using an unintelligent-but-regular distribution sequence (round-robin DNS
and routers) or a predefined threshold or algorithm (specialized clustering software) that
you specify and can adjust for each server in the cluster.
Clustering for failover relies on redundant servers to ensure that business-critical
applications remain available if one of the servers in a cluster fails. Intelligent
software-based failover solutions can detect when a server has failed and automatically
redirect new incoming HTTP requests to available cluster members. Some
hardware-based failover devices that have less built-in intelligence require an
administrator’s intervention when a failure is detected.
Clustering can be accomplished using software-based solutions, such as round-robin
DNS alone or together with a third-party package; a hardware-based solution, such as a
packet router; or a combination of the two.
28 Chapter 2 Scalability and Availability Overview
Hardware-based clustering solutions
A common and reliable hardware-based clustering solution is a packet router. One of the
most popular routers is Cisco Systems’ LocalDirector. A router, in front of a cluster of
web servers, directs incoming HTTP requests to available web servers in the cluster. A
router works by assessing the rate and volume of IP packet flow to and from web servers,
and selecting the best server to accommodate the traffic. This process is fast and efficient.
The router and clustered web servers comprise a virtual server.
Routers are considered semi-intelligent devices because they can detect a server failure
and redirect requests to other servers. If a web server fails or stops responding, the router
stops sending packets to the unresponsive server. Routers are not considered fully
intelligent because, while they can redirect requests upon discovering a failure, they do
not let you configure redirection thresholds for individual servers. They also do not
support application-aware load balancing.
The following figure shows a router distributing requests in round-robin fashion to the
available servers in a web server cluster:
Advantages of hardware-based solutions
A hardware-based clustering solution, such as a router, is an attractive solution for the
following reasons:
• It uses proven technology
• It is has relatively low complexity
Creating scalable and highly available sites 29
• There are no recurrent licensing fees
• It is semi-intelligent; routers can load balance in a round-robin fashion, detect
failures, redirect traffic, and remove failed servers from a cluster.
Note: Load-balancing devices offer different features and capabilities.
Considerations
Carefully evaluate the following issues against a router’s attributes:
• Expense — hardware devices can be expensive relative to some software solutions,
even without yearly licensing fees.
• Single point of failure — if a problem develops on the load-balancing device itself and
it fails, your load-balancing and failover strategies do not work. Although some
load-balancing devices come with secondary systems for this reason, this additional
equipment often inflates the overall price of a hardware solution.
• Lack of application-awareness — the device cannot be tuned for particular types of
web applications (static vs. dynamic sites) or for the development tools used to build
them (scriptlets vs. JSP vs. CGI vs. ASP and so on). Consequently, a router cannot
measure the performance of a web application server.
• Limited intelligence — the device does not let you configure individual load and
redirection thresholds for each server in a cluster, so it cannot effectively manage load
to prevent failures.
Software-based clustering solutions
There are several kinds of software-based clustering solutions on the market. As with
hardware-based clustering solutions, there are strengths and weaknesses associated with
each. These software solutions include:
• Round-robin DNS — a very popular choice because of its relative simplicity and low
implementation cost, but does not include intelligence for load balancing or failover.
• Primary/backup clustering — cloned systems provide redundancy for one another.
This type of clustering does not provide parallel server load balancing.
• Smart clustering — combines the advantages of round-robin DNS and backup
clustering to provide simplicity with intelligence and redundancy.
ClusterCATS lets you easily create, optimize, and maintain “smart” clusters to support
your web applications. ClusterCATS runs on Windows, Solaris, and Linux platforms and
works with leading mission-critical web servers, including Microsoft IIS, Netscape
Enterprise Server, and Apache. It is easily administered from remote locations and
provides robust features, including:
• Configuring load and redirection thresholds by server
• Optimizing the load-balancing scheme with application-aware and session-aware
load balancing
• Automatically detecting failures
• Automatically redirecting traffic to available servers
• Automatically notifying administrators of problems
30 Chapter 2 Scalability and Availability Overview
Advantages
Considerations
The following benefits make a software-based clustering solution attractive:
• Relatively low expense — compared to the cost of hardware devices, such as routers
or switches, software-based clustering solutions are relatively inexpensive. In fact, you
can cheaply implement Internet DNS on UNIX and Windows platforms for initial
load-balancing needs, and augment with third-party clustering software.
• Flexibility — some clustering software can augment existing hardware devices,
providing a more robust load-balancing and failover solution. By integrating
hardware with software, you diminish, if not eliminate, losses on capital expenditures
that your organization has already made. For more information, see “Combining
hardware and software clustering solutions” on page 32 and “Load-balancing devices”
on page 92.
• Intelligence — some software solutions provide a level of intelligence that enables
preventive load-balancing measures that actually minimize the chance of servers
becoming unavailable. If a server does becomes overloaded or actually fails, some
software can automatically detect the problem and reroute HTTP requests to
available servers in the cluster.
• No single point of failure — by distributing the load-balancing and failover
capabilities among multiple servers in a cluster or multiple clusters, as opposed to
relying on only a single device, no individual server failure can disable your
application.
Consider the following issues when evaluating software-based solutions for your
environment:
• Differences among feature sets — software-based clustering solutions differ in their of
capabilities and features. For instance, some lack automatic failure detection,
notification, or IP address assumption, and others have significantly delayed
detection. Some let you configure load thresholds to enable preventive measures, and
some don’t. Determine your scalability and failover needs in advance and pick your
solution accordingly.
• Platform constraints — determine whether the software solution is available on your
platform and operates with your preferred web server. When reviewing data sheets
and other marketing collateral from vendors, ensure that the robust features you want
are available on the platform you need.
• Level of complexity — some software-based clustering solutions relatively simple.
Others introduce more complexity because of the features offered, the amount of
initial configuration and subsequent administration, or the amount of integration
that must occur between other systems and devices.
Creating scalable and highly available sites 31
Combining hardware and software clustering solutions
Instead of having to choose either a hardware solution or a software solution, you can
combine both types of clustering choices. Combining hardware and software solutions
certainly provides the greatest scalability and availability capabilities for a site. A
combined solution is an attractive option if your organization has already invested in one,
but is looking for more comprehensive coverage. Having the flexibility to integrate
hardware with software means that your organization won’t necessarily have to absorb a
capital loss on a previous technology investment if you decide to purchase additional
clustering technology.
However, as already discussed, all hardware or software solutions are not equal. Many
have different features and capabilities, and not all hardware and software integrate well
together. Investigate thoroughly when purchasing technology to augment your current
solution.
For a visual representation of hardware and software clustering solutions working
together, see “Hardware-based clustering solutions” on page 29.
32 Chapter 2 Scalability and Availability Overview
CHAPTER 3
Installing ClusterCATS
Before installing ClusterCATS, you must make many important decisions about the
architecture of your website. Use the first section in this chapter to guide you through the
decision-making process. When you have installed ClusterCATS, read the last section in
this chapter for important information on how to make your site secure and reliable.
Contents
• Before you install...................................................................................................34
• Installing ClusterCATS.......................................................................................... 41
• After you install .....................................................................................................45
33
Before you install
Before installing ClusterCATS and creating server clusters, you must perform the
following pre-installation tasks:
• “Upgrading from a previous version of ClusterCATS” on page 34
• “Configuring DNS servers” on page 34
• “Configuring server failover” on page 38
• “Using ClusterCATS dynamic IP addressing” on page 38
• “Configuring firewalls” on page 38
• “Analyzing web server content” on page 39
• “Considering domain controllers (Windows NT only)” on page 40
Upgrading from a previous version of ClusterCATS
To update the ClusterCATS application while preserving your configuration settings,
re-install ClusterCATS using the instructions in this chapter. The ClusterCATS
installation detects that a configuration is available for use and prompts you by asking
whether you want to use the configuration in the new installation. You can use the
ClusterCATS Server setup options, or keep the existing cluster configurations.
Configuring DNS servers
ClusterCATS software requires that both the forward lookup (host name-to-address
translation) and reverse lookup (address-to-host name translation) be registered with
your DNS server. For evaluation purposes, you can use host files, but this is not
recommended in a production environment.
Note: ClusterCATS does not support Dynamic Host Configuration Protocol (DHCP). A
unique IP address must be assigned to each web server.
This section addresses the following topics:
• “Understanding DNS servers” on page 34
• “Configuring your primary DNS server” on page 36
Understanding DNS servers
When you enter a URL into a web browser, the browser is able to locate the website you
want to visit because of the name-to-IP address translation that the Internet Domain
Name System (DNS) performs. This section reviews two important components of the
DNS infrastructure that enable this capability — primary DNS servers and local DNS
servers.
Primary DNS servers
The primary DNS server provides the final mapping of a website name to the computer
on which a website resides. The primary DNS server can be located anywhere on the
Internet, but most reside either in the same physical location as the web servers or at the
ISP that provides the connection between the web servers and the Internet.
34 Chapter 3 Installing ClusterCATS
The primary DNS server contains tables of forward and reverse name translations. For
example, forward translation entries (A records) look like this:
www1.company.com 192.168.0.1
www2.company.com 192.168.0.2
Reverse translation entries (PTR records) are opposite, and look like this:
192.168.0.1 www1.company.com
192.168.0.2 www2.company.com
Configure your websites with forward and reverse DNS entries on your primary DNS
server. If you are not responsible for maintaining your primary DNS server, tell your
DNS administrator to add forward and reverse entries for your explicit web server names
(www1.company.com, www2.company.com, and so on).
Note: ClusterCATS does not operate correctly unless both forward and reverse
translations are configured for each explicit web server.
Local DNS servers
A local DNS server usually resides at a web hosting facility. The local DNS server stores
its own local table of name translations for the websites that the browser visits. If a user
enters a URL in a browser that the browser has already visited, it retrieves the host
name-to-IP address translation from the local DNS server’s table. However, if a user
enters a URL for a site that the browser on that computer has never visited, the local
DNS server must access the primary DNS server on the Internet to resolve the
name-to-IP mapping before the browser can send a request to the appropriate web server.
To summarize, primary and local DNS servers work together to resolve name-to-IP
address mappings in the following way:
1 A user enters a website URL in a browser.
2 The browser checks the local DNS server for the name-to-IP address mapping. This
server typically resides at the facility where the web servers are hosted.
3 If the local DNS server does not have the mapping, it goes to the Internet and locates
the primary DNS server to look up the name-to-IP address mapping.
If round-robin DNS is in use, the primary DNS server determines which server in
the cluster is next in line to receive the request.
4 The primary DNS server sends the translation to the local DNS server, which in turn
sends it to the user’s browser.
5 The browser sends an HTTP request to the correct web server hosting the site.
Before you install 35
The following diagram shows this process:
Configuring your primary DNS server
You must configure DNS so the forward and reverse lookup translation entries are
entered and registered correctly with your primary DNS server. To do this, you must
define DNS A and PTR DNS records for the web servers on your primary DNS server.
Besides standard name translations, your primary DNS server can distribute HTTP
requests sequentially across clustered servers, using a technique called round-robin DNS.
This service lets DNS return a list of multiple servers to the browser that requests a name
translation.
Round-robin DNS and ClusterCATS work well together. You should not rely on just
round-robin DNS for distributing load for your business-critical sites, because DNS
functionality is limited. In short, DNS is a good load distribution technique, but it
cannot manage load because it cannot react to increases in server traffic. It also cannot
detect server failures, nor redirect requests among available servers. ClusterCATS
compensates for these limitations.
Macromedia recommends that you use round-robin DNS or a hardware load-balancing
device to distribute requests initially to the web servers in your cluster. After the initial
distribution, ClusterCATS load management and failover features automatically take
over and ensure that your web applications remain up and running.
36 Chapter 3 Installing ClusterCATS
Using ClusterCATS with round-robin DNS
For high-volume sites, you should use round robin DNS to initially distribute requests to
the web servers in your cluster. The load management component of ClusterCATS
enhances round-robin DNS by eliminating its two major limitations:
• Server failure — round-robin DNS cannot detect server failure. Should a server in a
cluster fail, another server on the subnet immediately and transparently assumes the
IP address of the failed server.
• Server overload — round-robin DNS cannot detect server overloads. ClusterCATS
lets you configure load thresholds for each server. Should actual server load exceed the
load threshold, ClusterCATS transparently redirects users to another web server,
using an HTTP redirect. When redirected, user requests and responses flow to and
from that server directly, minimizing response time throughout the user session.
You must ensure that round-robin DNS entries are configured correctly on your primary
DNS server so ClusterCATS operates effectively with round-robin DNS. For example,
for a single-location server cluster consisting of four servers, you must configure
round-robin DNS across all four servers for the domain name, and individual IP
addresses for each explicit server name.
For example, the DNS table forward entries on your primary DNS server would be
similar to these:
Host Name IP Address
www.company.com 193.168.0.1
www.company.com 193.168.0.2
www.company.com 193.168.0.3
www.company.com 193.168.0.4
www1.company.com 193.168.0.1
www2.company.com 193.168.0.2
www3.company.com 193.168.0.3
www4.company.com 193.168.0.4
The DNS table reverse entries on your primary DNS server would be similar to these:
IP Address Host Name
193.168.0.1 www1.company.com
193.168.0.2 www2.company.com
193.168.0.3 www3.company.com
193.168.0.4 www4.company.com
Note: When using round-robin DNS, do not define a reverse mapping (PTR record) for the
site name (www.company.com); the cluster will not operate properly if you do. Define only
forward mappings (A records) for www.company.com. Define A records and PTR records
for all explicit servers (www1, www2,...) in the cluster. This configuration ensures that
requests cycle through the servers sequentially, or “round-robin.”
Before you install 37
Round-robin DNS distributes the initial domain-level requests across all four servers.
Thereafter, ClusterCATS distributes load to avoid failed or overloaded servers.
Configuring server failover
ClusterCATS protects clusters from server hardware and software failures. When a server
is no longer sending or receiving packets from the network, its IP address (and, therefore,
its HTTP requests) are assumed by another cluster member, which picks up HTTP
traffic originally addressed to the failed server. Server failover services are provided per
subnet.
Server failover is an option to select during the installation process. If you do not do so,
you must reinstall ClusterCATS and select that option. On Windows systems, preparing
your site for ClusterCATS Server failover can require uninstalling your web server
software. For more information, see “Using server failover” on page 137.
Using ClusterCATS dynamic IP addressing
You can set up your website so ClusterCATS dynamically assigns IP addresses to your
web servers. This addressing scheme includes a static maintenance address for each server
that lets you and ClusterCATS contact the server at any time, even during a web server
failure.
The setup for ClusterCATS dynamic IP addressing varies depending on your cluster’s
operating system:
• Windows — If your IP address for the local system is the same as the IP of your web
server, setting up your site for ClusterCATS dynamic IP addressing can involve
reinstalling your web server software and resetting your TCP/IP settings. Consider
this carefully before installing ClusterCATS. For more information, see
“ClusterCATS dynamic IP addressing (Windows only)” on page 132.
• UNIX — It is not necessary to configure a UNIX system for dynamic IP addressing
because it is set up by default if you select that option during installation.
Configuring firewalls
Many corporate environments today rely on firewalls to securely control access to
proprietary knowledge that resides on public Internet sites, internal intranet sites, or
private extranet sites. You can configure ClusterCATS to work seamlessly across one or
more firewalls.
A common technique is to use NAT as a security precaution on your firewall. This
configuration segregates internal and external resources and facilitates extra control and
monitoring of web traffic. For more information, see Macromedia Knowledge Base
Article 15339.
If multiple, distributed server clusters support a domain, you must open appropriate
ports on each firewall to ensure that the server clusters’ load-balancing and failover
features work. For example, if you cluster multiple, distributed web servers that have a
firewall between them, you must open ports 9123 and 9129 on the firewall that separates
them to enable server-to-server communications. Also, if you will manage your cluster
38 Chapter 3 Installing ClusterCATS
from behind another firewall, you must open both ports so the ClusterCATS Explorer
can communicate with the cluster.
The following diagram shows this scenario:
This scenario involves Company ABC, which has East Coast and West Coast server
groups connected to the Internet, protected by several firewalls. The ClusterCATS
Explorer resides at the corporate headquarters behind a firewall with a direct connection
to the Internet.
You must open and configure the appropriate communication ports on your firewalls to
allow server-to-server communication in a distributed setting and server-to-client
communication.
Note: You must open both ports on all affected firewalls.
These ports include the following:
• Port 9123 (for TCP and UDP access) — opening port 9123 on a firewall allows
multiple, distributed server clusters residing in different locations to communicate
with one another across firewalls
• Port 9129 (for TCP and UDP access) — opening port 9129 on a firewall allows
ClusterCATS Explorer to communicate with multiple, distributed server clusters
across firewalls
Analyzing web server content
All web servers, virtual servers, or websites in a cluster must have identical content.
You should specify the same default document for each web server in the cluster. For
example, set the default document to
default.jsp.
Before you install 39
Considering domain controllers (Windows NT only)
If you use Windows NT Domain server authentication, each web server in a cluster must
participate as a member NT server in a domain. Do not set a server in your cluster as the
primary domain controller (PDC). ClusterCATS Server failover will interfere with the
function of the PDC. An NT server can be a backup domain controller, but this is not
the recommended configuration.
40 Chapter 3 Installing ClusterCATS
Installing ClusterCATS
ClusterCATS is a separate installation package from the JRun server installation
program. You must install the ClusterCATS load-balancing and high-availability software
on each servers in your cluster. You can run the installation program to install
ClusterCATS on a separate, nonclustered computer from which you will administer your
clusters with ClusterCATS Explorer (Windows).
Before installing ClusterCATS on a platform, review the pre-installation steps described
in “Before you install” on page 34.
This section describes the following:
• “Installing ClusterCATS on Windows” on page 41
• “Installing ClusterCATS on UNIX” on page 42
Installing ClusterCATS on Windows
ClusterCATS supports the Microsoft Internet Information Server (IIS) 4.0 and
Netscape/iPlanet Enterprise Server on Windows NT 4.0 (with Service Pack 4 or later)
and IIS 5.0 on Windows 2000 and Windows .NET Server.
To install ClusterCATS on Windows servers:
1 Run the ClusterCATS setup.exe file from Windows Explorer or the Run dialog
box.
2 Accept the default installation directory, or click Browse to select a different directory
and click Next. In this manual, the installation directory is referred to as
<
CC_install_directory>.
3 Use the following table to determine which components to install. For more
information, see “ClusterCATS components” on page 6.
Component Reason to Select Component
ClusterCATS Explorer To use this computer to administer other ClusterCATS
Servers in your clusters. This computer can also be a member
of the cluster with the ClusterCATS Server component.
ClusterCATS Server If you are adding this computer as a member of a cluster. This
component includes the Server Administrator.
Documentation To make ClusterCATS documentation accessible from this
computer.
If more than one of the supported web servers is running, the Select Web Server
dialog box appears.
4 Select the web server to which you want ClusterCATS to bind. ClusterCATS does
not support clustering different types of web servers on one computer.
5 Select a method of load management.
Note: You must select JRun (JSP) Performance to have ClusterCATS manage the
JRun server load.
Installing ClusterCATS 41
The following table describes your options:
Method Reason to Select Option
HyperText Transport
Protocol (HTTP)
JRun (JSP) To have ClusterCATS load manage your JRun server’s JSP
ColdFusion (CFM) To have ClusterCATS load manage your ColdFusion server’s
6 In the Server Fail-Over dialog box, to enable this server to assume the IP address of a
failed server, click Yes. To prevent this computer from assuming a failed server’s IP
address, click No.
Note: If you use Cisco LocalDirector with ClusterCATS, select No for server failover. If
ClusterCATS performs dynamic IP addressing, the LocalDirector will not be able to
recover the failed-over IP address.
For more information, see “Using server failover” on page 137.
7 You are prompted to open ClusterCATS Explorer right away. By doing so, you can
add the new server to a cluster or create a cluster. If you are going to use this server as
the administration computer, you are not required to add it to a cluster.
Installing ClusterCATS on UNIX
To install ClusterCATS on UNIX, you must have the following information:
• The names of the web server on which you will install ClusterCATS
• root access to the systems on which you will install ClusterCATS
• The names, types, and install directories of the web servers you will be clustering
• The directory where JRun is installed
Note: The procedures in this section assume you have installed JRun.
ClusterCATS supports the Apache Web Server and the Netscape Enterprise Server on
Solaris platforms, and the Apache Web Server on Linux.
For more information about installation options, enter ? at any prompt during the
installation procedure. Default selections appear in brackets
To have ClusterCATS load manage just your web server’s
HTTP requests.
and servlet requests.
CFML page requests. You must have ColdFusion Server
installed for this option to take effect.
[default].
To install ClusterCATS on UNIX:
1 Enter the following command as root:
./cluster_install
The ClusterCATS installation welcome message appears.
Do you wish to continue with this installation? [yes]?
2 Enter Yes to continue with the installation or No to exit the installation.
The license agreement confirmation message appears.
Do you agree to the license terms? [no]?
42 Chapter 3 Installing ClusterCATS
3Review the license.txt file that is supplied with ClusterCATS. If you agree with
the licensing terms, enter Yes at the prompt. If you do not agree with the licensing
terms, enter No. Entering No terminates the installation procedure.
The installation directory prompt appears.
Enter install directory for ClusterCATS Server: [/opt]:
4 Enter the base directory where ClusterCATS will be installed, or press Enter to accept
the default. The installation creates a
./btcats subdirectory under the base
directory.
Note: The base directory (such as /opt) must exist prior to the installation.
The installation continues with the Configure Web Server Specific Information
section.
If you are installing ClusterCATS on Linux, skip to the next step.
If you are installing ClusterCATS on Solaris, you are prompted to enter the type of
web server to bind ClusterCATS to:
Enter Web Server type (Netscape, Apache, or <cr> to continue):
5 On Solaris, enter your web server type. On Linux, continue with the Apache
instructions in this step.
Apache: You are prompted to enter Apache’s installation directory and then the
location of the Apache
Enter Apache installation directory: [/usr/local/apache]:
Enter location of Apache config file httpd.conf: [/usr/local/apache/conf]:
config file:
Netscape: You are prompted to enter the location of Netscape’s root directory:
Enter Netscape Enterprise Server Root: [/usr/netscape/suitespot/https-server]:
6 Enter the configuration file location. ClusterCATS prompts you to optimize load
balancing for this server:
Optimize load balancing for either HTTP or JRun on https-<yourserver> [HTTP]:
ClusterCATS prompts you for the JRun installation directory:
Enter install directory for JRun []:
7 Enter the directory. ClusterCATS prompts you to turn on failure monitoring:
Monitor Web Server for Failures? [yes]?
8 Enter Yes to have monitoring turned on for this server. Enter No to disable
monitoring.
ClusterCATS optionally supports monitoring and restarting the web server on server
failure. Failures include the server not running or not responding to HTTP requests.
ClusterCATS prompts you to enable server failover on this server:
Enable ClusterCATS Server instance for Failover? [yes]?
9 Enter Yes to enable this server to assume the IP addresses for a failed cluster member,
and to pick up all the HTTP traffic originally addressed to the failed server. Enter No
to skip failover support for this server.
For more information, see “Using server failover” on page 137.
Installing ClusterCATS 43
If you are configuring ClusterCATS with Netscape and selected Yes, you are
prompted to decide which servers in the cluster this server will provide failover
support for:
Cluster Mates to provide Failover for: all, subset, none [all]:
10 Netscape only: Enter all to provide failover support to all members of this server’s
cluster. Enter subset to explicitly define the cluster members for which this server will
provide failover support. Enter none to disable server failover.
If you entered subset, you are prompted to enter a list of the ClusterCATS Server
Members that are allowed to fail over to this server. For more information, see the
online help.
11 Restart your web server for the changes to take effect.
44 Chapter 3 Installing ClusterCATS
After you install
When you have successfully installed ClusterCATS on all members of the cluster and any
administrative computers, you are ready to create your first cluster.
If you administer ClusterCATS from a Windows computer, you can use the Cluster
Setup Wizard described in “Creating clusters with the Cluster Setup Wizard” on page 54,
or manually create the cluster using the procedure described in “Creating clusters” on
page 54.
If you administer ClusterCATS from a UNIX computer, see “Creating clusters in UNIX”
on page 60.
Regardless of the method you use to create your first cluster, you should familiarize
yourself with the procedures in the following table when implementing your web
applications in a clustered environment:
Option Description
Load thresholds
for servers
Email addresses
for alarm
recipients
Session-aware
load balancing
Administering
with the
ClusterCATS We b
Explorer
Administrative
authentication
Two response time thresholds configured for each server. THe first
defines maximum or busy load; the second activates load
management. If the load for the server exceeds the busy threshold, no
new sessions can start on that server. If another server in the cluster
has the capacity to handle additional users, requests are redirected to
it. The load management activation threshold is referred to as the
gradual redirection threshold and is designed to prevent the server
from reaching the peak threshold.
For more information, see “Server load thresholds” on page 66.
ClusterCATS generates alarm notifications for several events,
including HTTP server failures, low disk space, server busy, and web
server failover. You provide e-mail addresses of all administrators for
ClusterCATS to notify for each generated alarm notification.
For more information, see “Administrator alarm notifications” on page
98.
If your web applications use session variables that store information in
web server memory, you should enable session-aware load balancing.
This feature prevents users who have established a session from being
redirected to another server as a result of load balancing.
For more information, see “Session-aware load balancing” on page 72.
If you use a UNIX computer to administer your cluster with
ClusterCATS Web Explorer, you must configure your web server to
host the Web Explorer pages.
For more information, see “Configuring the communications port on
your web server” on page 50.
Password protect administrative access to your cluster members using
domain accounts (NT only) or local accounts on each system (UNIX
and NT). Administrative users must also be members of the group sys,
or a special BT_<clustername> group.
For more information, see “Administering security” on page 103.
After you install 45
46 Chapter 3 Installing ClusterCATS
CHAPTER 4
Configuring Clusters
When you have configured your website and installed ClusterCATS, use the procedures
in this chapter to create and configure clusters.
Contents
• Introduction to ClusterCATS Administration........................................................ 48
• Creating clusters ....................................................................................................54
• Removing clusters.................................................................................................. 62
• Adding cluster members ........................................................................................ 63
• Removing cluster members.................................................................................... 65
• Server load thresholds............................................................................................ 66
• Session-aware load balancing .................................................................................72
• Persistent session failover in JRun ..........................................................................74
• Using ColdFusion probes ......................................................................................77
• Using JRun probes................................................................................................. 84
• Load-balancing devices ..........................................................................................92
• Administrator alarm notifications.......................................................................... 98
• Administrator e-mail options...............................................................................100
• Administering security......................................................................................... 103
47
Introduction to ClusterCATS Administration
ClusterCATS consists of these components:
• ClusterCATS Server
• ClusterCATS Explorer and ClusterCATS Web Explorer
• ClusterCATS Server Administrator and btadmin
The following sections describe these components.
All the components are installed on a computer when you run the ClusterCATS
installation program.
You must run the installation program on each server that will be part of your cluster, and
on the Windows computer from which you will use ClusterCATS Explorer to administer
the cluster. Even if your clusters run on Solaris or Linux platforms, you can use a
Windows computer to run the ClusterCATS Explorer (recommended). You can also use
the Web-based Explorer in conjunction with included server utilities to administer your
clusters.
Note: Read the description of each component that is relevant to your installation in the
sections that follow. These sections contain important configuration information.
ClusterCATS Server
The ClusterCATS Server is the heart of the clustering and load balancing of
ClusterCATS. It must be installed on each server in your cluster. The server monitors the
status of all other web servers in a cluster and tracks application and transaction resource
availability. ClusterCATS Server runs on Windows, Sun Solaris, and Linux platforms. To
administer the ClusterCATS Server, use the ClusterCATS Server Administrator
(Windows) or the
Each ClusterCATS Server component performs the following functions:
• Intelligently manages HTTP load across web servers
• Proactively manages JRun or ColdFusion server load
• Provides failover support for every server in your cluster
• Proactively monitors JRun and or ColdFusion servers and applications
btadmin utility (UNIX).
ClusterCATS Explorer (Windows only)
ClusterCATS Explorer is a Windows-based administration utility that you use to create
and manage clusters from one computer. Using a Windows Explorer-like graphical
interface, you perform management tasks such as:
• Creating and removing clusters
• Adding and removing servers from a cluster
• Configuring load-balancing and high availability features
• Enabling administrator authentication privileges
• Configuring e-mail-based alarm notifications
• Monitoring clusters
48 Chapter 4 Configuring Clusters
Note: You can run the ClusterCATS Explorer from any server in the cluster, or you can run it
remotely. This flexibility gives administrators in different geographic locations the ability to
administer distributed clusters. You can also use ClusterCATS Explorer to administer UNIX
clusters from a single Windows computer. You can view multiple clusters from a single
Explorer.
The ClusterCATS Explorer presents a view of your cluster that is much like the view that
the Windows Explorer presents of the files and directories that reside on a PC, as shown
below.
The ClusterCATS Explorer interface includes four distinct areas:
• Menu bar — menu access to all ClusterCATS functionality
• Toolbar — shortcuts to the most frequently used ClusterCATS functions
• Left pane — views of cluster objects.
• Right pane — the folder and files for the object currently selected in the left pane
Each object in a ClusterCATS cluster configuration — clusters, servers, monitors, and
probes — is represented by a unique icon. You can manipulate the icons in much the
same manner as you expand and collapse directory trees in the Windows Explorer. For a
list of which icons represent which objects in the ClusterCATS Explorer, click the Icon
Legend button.
ClusterCATS Web Explorer (UNIX only)
You use the ClusterCATS Web Explorer (btweb) for administering UNIX-only clusters.
It is a graphical, cross-platform, Web-based utility used to create, configure, and
administer ClusterCATS clusters.
Note: ClusterCATS only installs ClusterCATS Web Explorer on UNIX servers, but you can
access it from any computer with an Internet browser.
The Web Explorer, like its Windows counterpart, is quite robust and lets you configure
and administer clusters easily. However, it does not contain the identical functionality
provided by the Windows-based ClusterCATS Explorer. The Web Explorer does not let
you do the following:
• Install ClusterCATS Web Explorer on an Windows server; it runs only from UNIX
servers
• Create and administer Windows servers that have security enabled
• Set or modify load thresholds with a graphical display
Introduction to ClusterCATS Administration 49
• Monitor the load hitting the server via a graphical display; the server’s load statistics
are only displayed textually on the Cluster Member List and Server Properties pages
• Integrate ClusterCATS with Cisco LocalDirector
If you require any of these capabilities, you should obtain a Windows computer and use
the Windows-based ClusterCATS Explorer for your cluster administration.
Configuring the communications port on your web server
Before you can open and use the ClusterCATS Web Explorer, you must ensure that a
communications port is configured to listen for HTTP requests on the Netscape or
Apache web server for which you installed ClusterCATS. You can access the
ClusterCATS Web Explorer only through the defined communications port on your web
server, which you configure using your web server’s administration utilities.
Note: For availability and security reasons, be sure to allow access to the ClusterCATS Web
Explorer only from a separate IP-based virtual host server on a port other than 80 and
password protect access to it.
Netscape considerations
By default, Netscape Enterprise Server assigns your web server a random, six-digit
communication port number. You can either use this assigned number or change it to
something easier to remember, like port 81.
If you are not familiar with configuring your web server’s communications ports, see the
Netscape Enterprise Server Administrator online help for instructions.
Apache considerations
Make the following changes to the Apache Web Server’s
ClusterCATS Web Explorer (
(
2222) specified in the example below with values appropriate for your system and enable
btweb). Replace the IP address (192.168.96.71) and port
authentication for the virtual directory.
### BTWeb Administration
httpd.conf file to enable the
Listen 192.168.96.71:2222
<VirtualHost 192.168.96.71:2222>
ServerAdmin root@localhost
DocumentRoot /usr/lib/btcats/btweb
DirectoryIndex default.htm
ServerName btweb
ErrorLog logs/btweb_error_log
CustomLog logs/btweb_access_log combined
### BTWeb stuff ###
AddHandler cgi-script .exe
<Directory "/usr/lib/btcats/btweb/">
Options FollowSymLinks
Options ExecCGI
AllowOverride None
Order allow,deny
Allow from all
AuthName "btcats admin tools"
AuthType Basic
50 Chapter 4 Configuring Clusters
AuthUserFile /usr/local/apache/conf/users
require user admin
</Directory>
</VirtualHost>
When you have configured your server, restart Apache. To access the Web Explorer, point
your browser to the IP address you entered as the
For information on using the
file list, see the Apache documentation.
Opening the Web Explorer
The ClusterCATS Web Explorer can be used from a computer that runs either Netscape
Navigator or Microsoft Internet Explorer versions 4.0 or greater.
To open the Web Explorer:
1 Open a web browser.
2 Enter the following URL in the browser’s address field:
For Netscape Enterprise Server v3.x:
http://<server-name>:<admin-port>/admin-serv/btweb/default.html
For Netscape Enterprise Server v4.0x:
http://<server-name>:<admin-port>/https-admserv/btweb/default.html
For Apache:
http://<virtual_host>:<admin-port>/default.html
servername
ClusterCATS, and
web server or virtual host is configured to listen for HTTP requests.
The Enter Network Password dialog box appears:
VirtualHost.
htpasswd utility to create and manage your authentication
or virtual_host is the name of the web server on which you installed
<admin-port> is the communication port number on which the
3 Enter your user name and password in the appropriate fields and click OK.
Note: The default user name and password is admin.
The ClusterCATS Web Explorer opens.
Introduction to ClusterCATS Administration 51
ClusterCATS Server Administrator
The ClusterCATS Server Administrator is a Windows-based utility that lets you perform
server-specific maintenance activities for each server in a cluster. Unlike the ClusterCATS
Explorer, which let you administer clusters from one central computer, you must run the
ClusterCATS Server Administrator from each server in your cluster.
The Server Administrator lets you:
• Change installation settings
• Add and remove the ClusterCATS filter from the web server service
• Stop and start the ClusterCATS service
• Reset a clustered server’s configuration to its preclustered state
The ClusterCATS Server Administrator lets you accomplish these tasks using an
easy-to-use graphical user interface.
To open the ClusterCATS Server Administrator, select Start > Programs >
Macromedia > ClusterCATS Server Administrator.
For more information on using the Server Administrator, see Chapter 5.
52 Chapter 4 Configuring Clusters
btadmin
btadmin is a scriptable utility that lets you perform server-specific maintenance activities
for each server in a cluster.
btadmin is available on UNIX and Windows servers.
Unlike the ClusterCATS Web Explorer, which lets you administer your entire cluster
from one central computer, you must use
btadmin lets you:
• Add and remove the ClusterCATS filter from the web server service
• Stop and start the ClusterCATS service
• Place a cluster member in maintenance mode
• Reset a clustered server’s configuration to its preclustered state
btadmin from each server in your cluster.
For more information, see “Using btadmin” on page 122.
Introduction to ClusterCATS Administration 53
Creating clusters
If you have performed the tasks described in “Before you install” on page 34 and you
have successfully installed ClusterCATS, you are ready to create server clusters.
This section explains the following:
• “Creating clusters in Windows” on page 54
• “Creating clusters in UNIX” on page 60
Creating clusters in Windows
You can create clusters using the Cluster Setup Wizard or manually, using the
ClusterCATS Explorer. It is easier and quicker to create and configure clusters completely
with the Cluster Setup Wizard.
This section describes how to create clusters in both ways:
• “Creating clusters with the Cluster Setup Wizard” on page 54
• “Manually creating clusters” on page 59
Creating clusters with the Cluster Setup Wizard
The ClusterCATS Explorer includes the Cluster Setup Wizard that makes creating and
configuring clusters easy. The wizard steps you through the required definition and
configuration steps. After creating a cluster with the wizard, you can use the
ClusterCATS Explorer to make any necessary changes.
To create a server cluster using the Cluster Setup Wizard:
1 Select Start > Programs > Macromedia > ClusterCATS Explorer.
The ClusterCATS Explorer opens:
2 Select Configure > Cluster Setup Wizard or click the Cluster Setup Wizard icon
in the toolbar.
54 Chapter 4 Configuring Clusters
The Create New Cluster dialog box appears:
3 Enter a name for your cluster and click Next.
Make your cluster names logically consistent with their purpose. For example, Sales
Web, Customer Support Web, and so on.
The List of Web Servers in the Cluster dialog box appears:
Creating clusters 55
4 Click Add to add available web servers to your cluster.
The Add New Server to Cluster dialog box appears:
5 Enter the fully qualified host name of a web server in the New Web Server Name field
(for example, doc.macromedia.com).
6 If you use the ClusterCATS dynamic IP addressing scheme and the maintenance IP
address is not bound to your NIC, select ClusterCATS Maintenance Support.
If you are not configuring this server for offline maintenance support, go to step 8.
Note: You can set the maintenance support option only when creating a cluster or
adding a cluster member to a cluster. You cannot configure or modify this option after
you have created and added the cluster member to the cluster.
Enabling maintenance support for clusters requires that you configure your cluster
for ClusterCATS dynamic IP addressing. For more information, see “ClusterCATS
dynamic IP addressing (Windows only)” on page 132.
7 Enter the fully qualified host name of the maintenance address (for example,
serv1.yourcompany.com) in the Maintenance Address field.
8 Click OK.
9 Repeat steps 4 through 8 for each web server you want to add to the cluster, and then
click Next to proceed.
The Load Management dialog box appears:
56 Chapter 4 Configuring Clusters
10 To use the default load threshold settings, click Next and go to step 13. If you do not
want to use the defaults, select the server and click Configure to configure new peak
and gradual redirect load thresholds for that cluster member.
The Load Thresholds dialog box appears:
11 Enter numerical values (not higher than 100%) in the Peak Load Threshold and
Gradual Redirect fields and click OK.
Set the peak load threshold below 100%, to accommodate the server’s processing
needs. Set the gradual redirection threshold lower than the peak threshold.
12 Click Next.
The Alert Notification dialog box appears:
13 Enter the name of your outbound SMTP mail server in the SMTP mail server field
and the e-mail address for a recipient of cluster alerts in the E-mail addresses field. If
multiple people will receive different alerts for different types of notification events,
go to step 14. Otherwise, click Next and proceed to step 16.
14 To configure different types of alerts to go to different people, click Details in the
Alert Notification dialog box.
The Alarm Notification dialog box appears.
15 Select an alert event and enter the e-mail address of the recipient.
If you want one person to receive the majority of alerts, click Propagate to
automatically fill each event’s Recipient column with the same e-mail address. Then
Creating clusters 57
manually change the few recipients that are different. If there are multiple recipients
for one alert event, separate e-mail address entries with commas. Click OK to return
to the Alarm Notifications dialog box and then click Next to proceed.
The Session State Management dialog box appears:
16 If your server cluster supports a site that must maintain persistent state on the same
web server during a user session, select Yes to enable session-aware load balancing.
Otherwise, select No and click Next.
The Load Balancing Device dialog box appears:
17 If you use a hardware-based load-balancing device in addition to ClusterCATS to
manage and distribute load, enter the name of the website that this device supports
(for example, www.yourcompany.com) and click Next.
18 Click Finish.
ClusterCATS creates the cluster you configured and displays it in the ClusterCATS
Explorer’s left pane.
58 Chapter 4 Configuring Clusters
Manually creating clusters
If you do not want to create your clusters using the Cluster Setup Wizard, you can create
them manually. If you manually create clusters, you must then add each cluster member
to a cluster, using the ClusterCATS Explorer.
To manually add cluster members to a cluster, see “Adding cluster members” on page 63.
To manually create clusters:
1 Select Start > Programs > Macromedia > ClusterCATS Explorer.
The ClusterCATS Explorer opens.
2 Select Cluster Manager > New Cluster, or right-click the Cluster Manager icon and
select New Cluster, or click the New Cluster button in the toolbar.
The Create New Cluster dialog box appears:
3 Add a new cluster using the fields as described in the following table:
Field Description
Cluster Name Enter a unique name for the cluster.
Make cluster names logically consistent with their purpose. For
example, Sales Web, or Customer Support Web.
Web Server
Name
Bring up in
passive mode
Enter the fully qualified host name (for example,
doc.macromedia.com) for the first server you want to be a
member of this cluster.
You cannot create an empty cluster; you must specify a web
server that will be part of the cluster. The first server that you add
to a cluster is known as the Admin Manager. The remaining
steps guide you in configuring the Admin Manager.
Select this checkbox to bring the Admin Manager up in Passive
mode. If you do not select this checkbox, the server will be
brought up in Active mode.
For more information, see “Changing active/passive settings”
on page 111.
Creating clusters 59
Field Description
ClusterCATS
maintenance
support
Maintenance
address
4 Click OK.
The cluster appears below the Cluster Manager icon in the ClusterCATS Explorer
left pane.
To manually add additional cluster members to your new cluster, see “Adding cluster
members” on page 63.
Creating clusters in UNIX
1 In the ClusterCATS Web Explorer, click the Create New Cluster link.
The Create New Cluster page appears:
Select the ClusterCATS Maintenance Support check box to
enable support for offline maintenance. The Admin Manager
must be configured with a maintenance IP address.
Using maintenance support requires that your cluster support
ClusterCATS dynamic IP addressing. For more information, see
“ClusterCATS dynamic IP addressing (Windows only)” on page
132.
Offline maintenance support is available only on Windows NT
server clusters. You can set the maintenance support option
only when creating a cluster or adding a cluster member to a
cluster. You cannot configure or modify this option after you
create and added a cluster member to a cluster.
Enter the fully qualified host name of the maintenance address
(for example, serv1.yourcompany.com). This field is accessible
only if you selected ClusterCATS Maintenance Support.
60 Chapter 4 Configuring Clusters
2 Add a cluster using the fields as described in the following table:
Field Description
Cluster Name Enter a unique name for the cluster.
Make cluster names logically consistent with their purpose — for
example, Sales Web, or Customer Support Web.
Web Server
Name
Enter the fully qualified host name (for example,
doc.macromedia.com) for the first server you want to be a member
of this cluster.
You cannot create an empty cluster; you must specify a web server
that will be part of the cluster. The first server that you add to a
cluster is known as the Admin Manager.
You cannot create an empty cluster; you must specify a web server
that will be part of the cluster.
3 Click OK.
ClusterCATS creates the cluster and displays its members on the Cluster Member
List page, as in the following figure:
Creating clusters 61
Removing clusters
To delete a cluster, you must delete each member from the cluster individually, using the
procedure described in “Removing cluster members” on page 65.
Note: When deleting cluster members, you must delete the Admin Manager (Windows) or
the Admin Agent (UNIX) last. This server is the first server you added to the cluster.
When the last cluster member has been removed, the cluster itself is deleted.
To determine which server is the Admin Manager in Windows:
1 Open the ClusterCATS Explorer.
2 Right-click on the cluster icon and select Configure > Administration.
The cluster’s Properties dialog box opens displaying the Administration tab. The
server designated as the Admin Manager is the active entry in the drop-down list.
To determine which server is the Admin Agent in UNIX:
1 In the ClusterCATS Web Explorer, click the Show Cluster link.
2 Enter the fully qualified host name of a server in the Web Server Name field.
3 Click OK.
The Cluster Member List page appears. If you get an "Error: Server
<cluster_member_name> could not be found", ensure that you used the correct, fully
qualified server name and that the server is running.
4 Click the Administration link. The Cluster Administration page appears. The Admin
Agent is the currently selected host in the Admin Agent field.
62 Chapter 4 Configuring Clusters
Adding cluster members
You can add servers to a cluster at any time. This section describes the following:
• “Adding cluster members in Windows” on page 63
• “Adding cluster members in UNIX” on page 64
Adding cluster members in Windows
Use the ClusterCATS Explorer to add servers to a cluster. If you used the Cluster Setup
Wizard (Windows only) to create a cluster and populate it with cluster members, you can
also add clusters using the following procedure.
To add an additional cluster member to a cluster:
1 Open the ClusterCATS Explorer and select a cluster.
2 Select Cluster > New > Cluster Member. Alternatively, you can click the Add button
or right-click the cluster icon and select New > Cluster Member.
The Add New Server to Cluster dialog box appears:
3 In the Web Server Name field, enter the fully qualified host name of the web server
(for example, doc.macromedia.com).
4 If you use the ClusterCATS dynamic IP addressing scheme and the maintenance IP
address is not bound to your NIC, select ClusterCATS Maintenance Support.
If you are not configuring this web server for offline maintenance support, go to step
6.
Note: You can set the maintenance support option only when creating a cluster or
adding a cluster member to a cluster. You cannot configure or modify this option after
you have created and added the cluster member to the cluster.
Enabling maintenance support for clusters requires that you configure your cluster
for ClusterCATS dynamic IP addressing. For more information, see “ClusterCATS
dynamic IP addressing (Windows only)” on page 132.
5 Enter the fully qualified host name of the maintenance address (for example,
serv1.yourcompany.com) in the Maintenance Address field.
6 Click OK.
7 Repeat steps 2 through 6 to add additional servers to the cluster manually.
Adding cluster members 63
Adding cluster members in UNIX
Use the ClusterCATS Web Explorer to add cluster members.
To add a cluster member to a cluster:
1 Open the ClusterCATS Web Explorer if it is not already open.
2 Click the Add Server link.
The Add Server page appears:
3 Enter the fully qualified host name (for example, doc.macromedia.com) in the
Web Server Name field.
4 Click OK to add the cluster member to the existing cluster.
64 Chapter 4 Configuring Clusters
Removing cluster members
You can remove servers from a cluster at any time. This section describes the following:
• “Removing cluster members in Windows” on page 65
• “Removing cluster members in UNIX” on page 65
Removing cluster members in Windows
Use the ClusterCATS Explorer to remove cluster members.
To remove a cluster member from a cluster:
1 Open the ClusterCATS Explorer and select a cluster member.
2 Select Server > Delete or right-click the server name and select Delete.
The selected cluster member is deleted from the cluster you selected.
Removing cluster members in UNIX
Use the ClusterCATS Web Explorer to remove cluster members.
To remove a cluster member from a cluster:
1 In the ClusterCATS Web Explorer, click the Delete Server link.
The Delete Server page appears:
2 Select a cluster member to delete from the Web Server Name drop-down box.
A message appears, telling you that the selected server has been deleted.
Note: If you delete the last cluster member in a cluster, the cluster is also deleted and
you are returned to the default page of the ClusterCATS Web Explorer.
3 Click OK.
Removing cluster members 65
Server load thresholds
ClusterCATS ensures that your web applications remain available and running at
optimum performance by intelligently managing the HTTP traffic hitting your clustered
servers. By setting load thresholds on each server in your cluster, you can control and
manage your site’s availability and performance. Many of your threshold configuration
decisions hinge on your site’s architecture and where the bulk of your processing
resources must be allocated.
During an HTTP redirection, ClusterCATS evaluates the cluster’s state according to the
HTTP server state first, and then the JRun/ColdFusion server load. This policy is the
same in centralized and distributed ClusterCATS configurations. In a centralized
ClusterCATS cluster with all web servers at one site, ClusterCATS redirects only if the
server is busy or restricted.
For each cluster member, you configure two load thresholds:
• Peak load threshold — the maximum load the server can handle before its
performance degrades significantly or becomes unavailable.
• Gradual redirection threshold — the point at which HTTP requests begin to be
redirected to other less-loaded members in a cluster so the server’s performance does
not degrade or become unavailable.
By default, the peak load threshold is 90% and the gradual redirection threshold is 10%.
These default settings adequately handle HTTP traffic going across most websites.
However, if your website is particularly processing intensive, you should lower both
threshold settings to better accommodate the increased load.
If you want the server to handle as much load as possible, set the threshold values close to
one another. However, if you want redirection to occur well in advance of the server
nearing its peak threshold, set the values farther apart so there is a difference of at least
10% between the two threshold values.
This section shows you how to set the peak and gradual redirection load thresholds for
ClusterCATS Servers in the following sections:
• “Configuring load thresholds in Windows” on page 66
• “Configuring load thresholds on UNIX” on page 69
Configuring load thresholds in Windows
To adjust load thresholds for a cluster member:
1 Open the ClusterCATS Explorer and select a server.
2 Select Server > Properties or right-click the server and select Properties.
66 Chapter 4 Configuring Clusters
The server’s Properties dialog box appears:
3 Click the Load tab.
4 Enter a numeric value (less than 100%) in the first Load Management field. This is
referred to as the peak load threshold. In the example above, the peak load threshold
is set to 90.
5 Enable the Gradual Redirection check box.
6 Enter a new value in the Gradual Redirection field. This value must be lower than the
peak load threshold.
7 Click OK to apply your new threshold settings.
Server load thresholds 67
Viewing a cluster’s load status
JRun/ColdFusion reports its load data directly to ClusterCATS. You can view the load on
the servers at any time using the Server Load Monitor.
To view your cluster’s current load levels:
1 Open the ClusterCATS Explorer and select a cluster.
2 Select Monitor > Load or right-click the cluster you have selected and select Monitor
> Load.
The Server Loads dialog box appears, showing the current load status for each cluster
member in the cluster that you selected:
The load monitor shows three lines:
• Top line (red): Peak load threshold
• Middle line (yellow): Gradual Redirection load threshold
• Bottom line (green): JRun/ColdFusion server load
Adjusting load threshold settings graphically
You can view and set threshold settings of a cluster member using the Server Load
Monitor’s visual display. To set or change threshold settings, use the mouse to drag the
Peak (red) and Gradual Redirection (yellow) threshold lines to their settings instead of
entering numeric values in fields
To configure load threshold settings using the Server Load dialog box:
1 Open the ClusterCATS Explorer and select a server.
2 Select Monitor > Load or right-click the server and select Monitor > Load.
68 Chapter 4 Configuring Clusters
The Server Load dialog box appears:
3 Use your mouse to drag the peak load threshold (red) up or down.
As you move the line, the peak load threshold percentage changes.
4 Enable gradual redirection by selecting the Gradual Redirection check box.
5 Drag the Gradual Redirection load threshold (yellow) to adjust it accordingly.
6 Close the dialog box to apply the load threshold settings you configured.
Configuring load thresholds on UNIX
To configure load thresholds for a cluster member:
1 In the ClusterCATS Web Explorer, click the Show Cluster link.
The Show Cluster page appears:
2 Enter the fully qualified host name of a server in the Web Server Name field.
Server load thresholds 69
3 Click OK.
The Cluster Member List page appears. If you get an "Error: Server
<cluster_member_name> could not be found", ensure that you used the correct, fully
qualified server name and that the server is running.
4 Click the Server Attributes link.
The Connect To Server page appears:
5 Select a server to connect to from the Web Server Name list box.
6 Click OK.
70 Chapter 4 Configuring Clusters
The selected server’s Server Properties page appears:
7 Click the Administration link under Server Attributes.
The Server Administration page appears for the selected server:
8 To change the peak load threshold, enter a new numeric value (less than 100%) in the
Standard Load Threshold field.
9 Enable the Gradual Redirection check box if it is not already enabled.
10 To change the Gradual Redirection load threshold, enter a new numeric value in the
Gradual Load Threshold field. This value must be lower than the standard load
threshold.
11 Click OK to apply your new load threshold settings.
Server load thresholds 71
Session-aware load balancing
Managing a web application’s state in a clustered environment can be challenging. By
default, web application, session, and server variables that are stored in memory or a
repository during a user session do not persist during a server redirection. Consequently,
the web server cannot maintain the application’s state correctly.
To overcome this problem, ClusterCATS provides a session-aware load-balancing feature
that lets you maintain application state in a clustered environment.
One way to maintain your web application’s state is to create session variables that are
stored on the web server. For an e-commerce website that is clustered, it is vital that users
do not get redirected to another server in the middle of their session. If they did, their
online transactions would be interrupted, making for an unsuccessful and frustrating user
experience.
To ensure that users are not redirected from the server on which they start their session,
ClusterCATS provides a built-in feature for enabling session-aware load balancing.
Sometimes referred to as a “sticky” server, session-aware load balancing guarantees that
users will not get bumped from the server on which they start their session until the
session is complete, regardless of the load thresholds that have been defined for that
server.
Note: Session-aware load balancing may not work if you use absolute hyperlinks in your
web pages. Absolute links route the HTTP request back to the cluster entry point and
redirect according to the current load threshold without regard to the state of the requesting
client. To avoid inadvertent loss of state, use only relative linking in your web pages.
This section describes the following:
• “Enabling session-aware load balancing on Windows” on page 72
• “Enabling session-aware load balancing on UNIX” on page 72
Enabling session-aware load balancing on Windows
To enable session-aware load balancing:
1 Open the ClusterCATS Explorer and select a cluster.
2 Select Configure > Administration or right-click the cluster and select Configure >
Administration.
The cluster Properties dialog box appears.
3 Select the Session State Management check box.
4 Click OK.
Enabling session-aware load balancing on UNIX
To enable session-aware load balancing:
1 In ClusterCATS Web Explorer, click the Show Cluster link.
2 Enter the fully qualified host name of a server for which you want to configure
session-aware load balancing in the Web Server Name field.
72 Chapter 4 Configuring Clusters
3 Click OK.
The Cluster Member List page appears:
4 Click the Administration link under Cluster Attributes.
The Cluster Administration page appears:
5 Select the Enable session-aware load balancing check box.
6 Click OK to enable session-aware load balancing for the selected cluster.
Session-aware load balancing 73
Persistent session failover in JRun
JRun can be configured to enable session persistence, meaning that all session data is
saved (persisted) upon the completion of every request. When a server that is servicing a
client's session goes down, the client's active session data can be retrieved intact from a
common data store (such as a JDBC database) by another server. When the client
attempts to continue its active session and presents its session ID to the replacement
server, its session data is restored from the repository, completing the session failover.
This feature is called session swapping. The client's session state is effectively swapped
from one server to another when the first fails.
Session swapping overview
The following are required to use failover for persistent sessions with ClusterCATS:
• Session swapping must be enabled in JRun and ClusterCATS. For more information,
see “Configuring JRun for session swapping” on page 74 and “Configuring
ClusterCATS for session swapping” on page 74, respectively.
• Session-aware load balancing must be enabled. Because only one server can be
responsible for a session at a time, JRun session swapping must be used in
conjunction with the ClusterCATS session-aware load-balancing feature. This ensures
that multiple servers do not have concurrent access to the same session data. For more
information, see “Session-aware load balancing” on page 72.
• A repository used for persistent session data must be shared among the JRun servers
in a cluster. For information, see “Using shared files for session swapping” on page
75. For an example of using JDBC to connect to a shared repository of session
information, see “Using JDBC for session swapping” on page 76.
• Cookies must have domain scope for proper session swapping. For more information,
see “Configuring JRun for session swapping” on page 74.
Configuring JRun for session swapping
To enable session swapping in JRun, the following properties must be set in the JRun
server’s
local.properties file:
session.swapping=true
session.maxresident=0
The local.properties file must enable domain scope for cookies by including the
following property:
session.cookie.domain=yourdomain.com
The repository used for session swapping can be a shared file or a shared JDBC database.
For information, see “Using shared files for session swapping” on page 75 and “Using
JDBC for session swapping” on page 76.
Configuring ClusterCATS for session swapping
ClusterCATS must be configured to allow session swapping to function properly. The
following platform-specific procedures explain how to enable session swapping in
ClusterCATS.
74 Chapter 4 Configuring Clusters
To enable session swapping on Windows:
1 Edit the registry (using regedit) and open the following key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BrightTiger\
Parameters
2 Add the following REG_DWORD value:
SessionSwapping 1
3 Close the registry editor.
4 Repeat this procedure for every server in the cluster.
To enable session swapping on UNIX:
1 Log in as the super user (root).
2 Stop ClusterCATS by issuing the following command:
# /usr/lib/btcats/btadmin stop all
3 Edit the file /usr/lib/btcats/database/bt.registry with a text editor.
4 Search for the following string:
hkey_local_machine\system\currentcontrolset\services\brighttiger\
parameters:5
Under the following entry:
Advertise: 0x2; REG_DWORD
Add the following line:
SessionSwapping: 0x1 ; REG_DWORD
5 Save the file and exit your text editor.
6 Restart ClusterCATS with the following command:
# /usr/lib/btcats/btadmin start all
7 Repeat this procedure for every server in the cluster.
Using shared files for session swapping
To use file swapping, the JRun server's local.properties file should contain the
following properties:
session.persistence.service=file
session.persistence.file.class=allaire.jrun.session.FileSessionStorage
# See the following paragraph for more on this property.
session.persistence.file.path=/mnt/myothermachine/sessionpool
The session.persistence.file.path property must specify a shared path that all
computers can read and write to. For example, on UNIX, you must have server1 export
sessionpool
server1:/sessionpool to some mount point — for example, /mnt/sessionpool —
and set server2’s
permission.
Note: If JRun runs as an NT service, and you use a mapped drive, JRun does not have
permissions to write to the drive. To correct this problem, edit the properties for the JRun
Service and change the user account for the service to be a user with the necessary
privileges to write to the mapped drive.
and server1's file.path=/sessionpool. Now server2 should mount
file.path=/mnt/sessionpool. This assumes that server2 has write
/
Persistent session failover in JRun 75
Using JDBC for session swapping
To use JDBC for session swapping, the JRun server's local.properties file should
contain the following properties:
session.persistence.service=jdbc
session.persistence.jdbc.class=allaire.jrun.session.JDBCSessionStorage
session.persistence.jdbc.JDBCDriver=sun.jdbc.odbc.JdbcOdbcDriver
session.persistence.jdbc.JDBCConnectionURL=jdbc:odbc:JRunSessions
session.persistence.jdbc.JDBCSessionTable=sessions
session.persistence.jdbc.JDBCSessionIDColumn=id
session.persistence.jdbc.JDBCSessionDataColumn=data
JDBC swapping requires that you have a valid JDBC driver that can successfully connect
to the database. You must create a table in your database with an id column and a data
column. This example uses a table named sessions, an IDColumn named id, and a
DataColumn named data. Define the id column as varchar(255) and the data column as
binary data.
76 Chapter 4 Configuring Clusters
Using ColdFusion probes
ClusterCATS provides load-balancing and failover support for your web applications in
two ways. First, it automatically interprets and reacts to the load metric that the
ColdFusion server generates. Second, ClusterCATS lets you create web application
monitors. These monitors can have multiple probes that periodically test the health and
operation of the websites that the servers process.
Note: Multiple probes are allowed per web server, and web applications can be restarted
individually. However, each web application should have only one probe that restarts on a
failure.
The probe is a high-availability feature that verifies that ColdFusion servers are running
properly on clustered servers. It periodically tests specific URLs at specified intervals and
verifies their validity against user-defined strings contained in the returned pages.
If the validation test succeeds, inbound HTTP requests continue to be sent to the server
for which the probe exists. However, if a test fails (the URL fails, times out, or does not
return the user-specified string in the page accessed), ClusterCATS restricts that server
and redirects requests to other available servers in the cluster. ClusterCATS continues to
test the restricted server; when the probe returns a valid value, the server is considered
available.
If a ColdFusion server hangs or fails, ClusterCATS attempts to recover the failed service.
When the service is recovered, the probe can restart the server and begin sending HTTP
traffic to it again.
This section describes the following:
• “Configuring ColdFusion probes in Windows” on page 77
• “Configuring ColdFusion probes in UNIX” on page 81
Configuring ColdFusion probes in Windows
This section describes the following:
• “Adding ColdFusion probes” on page 77
• “Removing ColdFusion probes” on page 81
Adding ColdFusion probes
ClusterCATS lets you set up one probe monitor for each server in the cluster. Each
monitor can have multiple probes associated with it. As a result, clusters will typically
have multiple probe monitors (one for each server), and each monitor can have one or
more probes.
The procedure for adding a new monitor and probe is different from adding a probe to a
server that already has a probe monitor. This section describes how to perform both
activities.
Note: The ColdFusion service must be running on your server to add a probe.
Using ColdFusion probes 77
To add a new monitor and ColdFusion probe:
1 Open the ClusterCATS Explorer and select a server.
2 Select Server > New Monitor. Alternatively, you can right-click the server and select
New Monitor.
The New Monitor dialog box appears:
3 Enter a name to assign to this probe’s monitor in the Name field and click OK.
The monitor’s Properties dialog box appears:
78 Chapter 4 Configuring Clusters
4 Click the New Probe button .
The ColdFusion Web Application Probe settings dialog box appears:
5 Configure the application probe settings as described in the following table:
Field Description
Web Server Select the name of the server from the drop-down list.
Pathname Enter the absolute path to the ColdFusion probe. Do not
Working directory Enter the absolute path to the probe’s working directory. Do
Startup parameters Replace the <URL> with the actual URL of the site you want
Timeout (sec) Enter a time, in seconds, to indicate how long ClusterCATS
change the default selection unless you installed ColdFusion
to a directory other than the default installation directory.
not change the default selection unless you installed
ColdFusion to a directory other than the default installation
directory.
the probe to access, and replace <success string> with a text
string that appears on a page on the site you are probing.
Tip s:
• Be sure to include a space between the URL and the
success string that you specify. The success string must
be enclosed in quotation marks.
• Do not modify the RESTART explicit parameter if you
want the probe to automatically restart the ColdFusion
Server upon detecting a failure. However, if you do not
want ClusterCATS to automatically restart the ColdFusion
Server upon detecting a failure, replace RESTART with
NORESTART.
should wait before a ColdFusion server failure is registered.
Do not set this value to less than 60 seconds because
ClusterCATS might restart the ColdFusion server
inadvertently (due to network congestion, for example),
rather than detect an actual failure on the ColdFusion server.
Using ColdFusion probes 79
Field Description
Frequency (sec) Enter a time, in seconds, to indicate how often the probe
Return Value Enter 0 so that the probe succeeds on a successful probing
checks the ColdFusion server.
Probes that restart web applications should be configured to
run no more frequently than the time it takes to stop and
restart ColdFusion. This time is highly site-specific, because
it depends on the system resources available on the servers
and the volume of traffic at the site.
For probes that do not restart the web application, the
Frequency depends on how long you can reasonably afford
to have your web application off-line. A minimum Frequency
of 15 seconds is recommended.
of the page. Enter a non-zero number to have the probe
succeed on a failure.
The default is 0. Only under rare circumstances would you
change this to a non-zero number.
6 Click Register to create the probe.
7 Close all open dialog boxes.
Icons for the monitor and probe appear under the Monitor Manager in the
ClusterCATS Explorer.
To add a new probe to an existing probe monitor:
1 Open the ClusterCATS Explorer.
2 Select the cluster_name > Monitor Manager > monitor_name in the left pane.
3 Select Monitor > Properties. The monitor’s Properties dialog box appears:
80 Chapter 4 Configuring Clusters
4 Click the New Probe button .
The ColdFusion Web Application Probe settings dialog box appears:
5 Configure the application probe settings as described in the table on page 79.
6 Click Register to create the probe.
7 Close all open dialog boxes.
An icon for the new probe appears under the Monitor Manager in the ClusterCATS
Explorer.
Removing ColdFusion probes
To remove a ColdFusion probe:
1 Open the ClusterCATS Explorer.
2 Select the cluster_name > Monitor Manager > monitor_name > probe_name in the left
pane.
3 Select Probe > Delete. Alternatively, you can right-click the probe and select Delete.
Configuring ColdFusion probes in UNIX
This section describes the following:
• “Adding ColdFusion probes” on page 81
• “Editing and removing ColdFusion probes” on page 83
Adding ColdFusion probes
To add a new ColdFusion probe:
1 Open the ClusterCATS Web Explorer if it is not already open.
2 Click the Show Cluster link.
The Show Cluster page appears.
3 In the Web Server Name field, enter the fully qualified host name of the server for
which you want to configure the ColdFusion probe.
4Click OK.
The Cluster Member List page appears.
5 Click the Server Attributes link.
The Connect To Server page appears.
6 Select the server to add a probe to from the Web Server Name listbox.
7Click OK.
The selected server’s Properties page appears.
8 Click the ColdFusion Probe link.
If there are existing probes for this server, the Probe List page appears.
Using ColdFusion probes 81
9 To create a new probe, click New.
The ColdFusion Application Probe page appears. If this is the first probe for this
server or you clicked New to add another probe, the ColdFusion Application Probe
page appears.
10 Configure the application probe settings as described in the following table:
Field Description
Status This is an informational field. If the probe is not registered, the
Status displays Not registered. If the probe is registered, the
Status displays Succeeding.
Pathname Enter the path to the ColdFusion probe. Do not change the default
selection unless you installed ClusterCATS for ColdFusion to a
directory other than the default installation directory.
Working directory Enter the path to the probe’s working directory. Do not change the
default selection unless you installed ClusterCATS for ColdFusion
to a directory other than the default installation directory.
Startup Parameters Enter the actual URL of the site you want the probe to access
followed by a text string that appears on a page within the site you
are probing (cfprobe.cfm in the screen shown in step 9.)
Note: Do not modify the RESTART explicit parameter if you want
the probe to automatically restart the ColdFusion Server upon
detecting a failure. However, if you do not want ClusterCATS to
automatically restart the ColdFusion Server upon detecting a
failure, replace RESTART with NORESTART.
Timeout (sec) Enter a time, in seconds, to indicate how long ClusterCATS should
wait before a ColdFusion server failure is registered.
Do not set this value to less than 60 seconds because
ClusterCATS might restart the ColdFusion server inadvertently
(due to network congestion, for example), rather than detect an
actual failure on the ColdFusion server.
Frequency (sec) Enter a time, in seconds, to indicate how often the probe checks
the ColdFusion server.
Probes that restart web applications should be configured to run
no more frequently than the time it takes to stop and restart
ColdFusion. This time is highly site-specific, because it depends
on the system resources available on the servers and the volume
of traffic at the site.
For probes that do not restart the web application, the Frequency
depends on how long you can reasonably afford to have your web
application off-line. A minimum Frequency of 15 seconds is
recommended.
Return value Enter 0 so that the probe succeeds on a successful probing of the
page. Enter a non-zero number to have the probe succeed on a
failure.
The default is 0. Only under rare circumstances would you change
this to a non-zero number.
82 Chapter 4 Configuring Clusters
11 Click Register to create the probe. ClusterCATS begins to test the selected server
immediately.
Editing and removing ColdFusion probes
To edit or remove a ColdFusion probe:
1 Open the ClusterCATS Web Explorer, if it is not already open.
2 Click the Show Cluster link.
The Show Cluster page appears.
3 Enter the fully qualified host name of the server for which you want to configure the
ColdFusion probe in the Web Server Name field.
4 Click OK. The Cluster Member List page appears.
5 Click the Server Attributes link.
The Connect To Server page appears.
6 Select the server that hosts the probe in the Web Server Name lis tbox.
7Click OK.
The selected server’s Properties page appears.
8 Click the ColdFusion Probe link.
The Probe List page appears.
9 Select the probe to edit or remove.
10 To remove the probe, click Delete.
ClusterCATS removes the ColdFusion probe.
11 To edit the probe, click Edit.
A page with all the available probes appears.
12 Edit the fields corresponding to the probe that you want to change, and click
Register.
Using ColdFusion probes 83
Using JRun probes
ClusterCATS provides load-balancing and failover support for your web applications in
two ways. First, it automatically interprets and reacts to the load metric that the JRun
servers generate. Second, ClusterCATS lets you create web application monitors. These
monitors can have multiple probes that periodically test the health and operation of the
websites that the JRun servers process.
Note: Multiple JRun probes are allowed per web server, and JRun web applications can be
restarted individually. However, each web application should have only one probe that
restarts on a failure.
The probe is a high-availability feature that verifies that JRun servers are running
properly on clustered servers. It periodically tests specific JRun URLs at specified
intervals and verifies their validity against user-defined strings contained in the returned
pages.
If the validation test succeeds, inbound HTTP requests continue to be sent to the server
for which the probe exists. However, if a test fails (the URL fails, times out, or does not
return the user-specified string in the page accessed), ClusterCATS restricts that server
and redirects requests to other available servers in the cluster. ClusterCATS continues to
test the restricted server; when he probe returns a valid value, the server is considered
available.
If the JRun server hangs or fails, ClusterCATS attempts to recover the failed service.
When the JRun service is recovered, the probe can restart the JRun server and begin
sending HTTP traffic to it again.
This section describes the following:
• “Configuring JRun probes in Windows” on page 84
• “Configuring JRun probes in UNIX” on page 88
Configuring JRun probes in Windows
This section describes the following:
• “Adding JRun probes” on page 84
• “Removing JRun probes” on page 88
Adding JRun probes
ClusterCATS lets you set up one probe monitor for each server in a cluster. Each monitor
can have multiple probes associated with it. As a result, clusters typically have multiple
probe monitors (one for each server), and each monitor may have one or more probes.
The procedure for adding a new monitor and probe is different from adding a probe to a
server that already has a probe monitor. This section describes how to perform both
activities.
Note: The JRun service must be running on your server to add a probe.
84 Chapter 4 Configuring Clusters
To add a new monitor and JRun probe:
1 Open the ClusterCATS Explorer and select a server.
2 Select Server > New Monitor or right-click the server and select New Monitor.
The New Monitor dialog box appears:
3 Enter a name to assign to this probe’s monitor in the Name field on the New Monitor
dialog box and click OK.
The monitor’s Properties dialog box appears:
Using JRun probes 85
4 Click the New Probe button .
The JRun Application Probe settings dialog box appears:
5 Configure the application probe settings as described in the following table:
Field Description
Web Server Select the name of the server from the drop-down list.
Pathname Enter the absolute path to the JRun probe. Do not change the default
Wo rk in g
directory
Startup
parameters
selection unless you installed JRun to a directory other than the
default installation directory.
Enter the absolute path to the probe’s working directory. Do not
change the default selection unless you installed JRun to a directory
other than the default installation directory.
Enter parameters passed to the probe on execution using the
following syntax:
URL success_string [RESTART|NORESTART|
<JRun_server>] [LOG|NOLOG]
86 Chapter 4 Configuring Clusters
URL — enter the actual URL of the page you want the probe to test. By
default, this is http://<your_server>/btauxdir/jrunprobe.jsp. The probe
opens the page and searches for the success_string.
success_string — enter a text string that appears at the page
specified by the URL. If the success_string includes spaces, it must
be enclosed in quotation marks.
RESTART|NORESTART — enter RESTART to make the probe
automatically restart the default JRun server on probe failure. Enter
NORESTART if you do not want ClusterCATS to restart the JRun server
on a failure. If you installed JRun as a service, replace RESTART with
Service-<service_name> to restart a particular service, or replace
RESTART with the name of a specific JRun server (such as admin) to
restart.
LOG|NOLOG — enter LOG to enable logging for the ClusterCATS
application probe or NOLOG to disable it. The probe logs are stored in
the /<CC_install_directory>/log/ directory.
The default for Startup Parameters is http://<your_server>/btauxdir/
jrunprobe.jsp Hello NORESTART NOLOG
Field Description
Timeout (sec) Enter a time to indicate how long ClusterCATS waits before a JRun
Fr eq u en c y
(sec)
Return value Enter 0 to make a probe succeed on a successful probing of the page.
server failure is registered.
Do not set this value to less than 60 seconds, because ClusterCATS
may restart the JRun server inadvertently (due to network congestion,
for example), rather than detect an actual failure on the JRun server.
Enter a time to indicate how often the probe checks the JRun server.
Probes that restart web applications should be configured to run no
more frequently than the time it takes to stop and restart JRun. This is
highly site-specific, because it depends on system resources available
on servers and the volume of traffic at a site.
For probes that do not restart the web application, the frequency
depends on how long you can reasonably afford to have your web
application offline. A minimum frequency of 15 seconds is
recommended.
Enter a non-zero number to make a probe succeed on a failure.
The default is 0. Only under rare circumstances would you change this
to a non-zero number.
6 Click Register to create the probe.
7 Close all open dialog boxes.
Icons for the monitor and probe appear under the Monitor Manager in the
ClusterCATS Explorer.
To add a new probe to an existing probe monitor:
1 In the ClusterCATS Explorer, select the cluster_name > Monitor Manager >
monitor_name in the left pane.
2 Select Monitor > Properties.
Using JRun probes 87
The monitor’s Properties dialog box appears:
3 Click the New Probe button .
The JRun Application Probe settings dialog box displays.
4 Configure the application probe settings as described in the table in “Using JRun
probes” on page 84.
5 Click Register to create the probe.
6 Close all open dialog boxes.
An icon for the new probe appears under the Monitor Manager in the ClusterCATS
Explorer.
Removing JRun probes
To remove a JRun probe:
1 Open the ClusterCATS Explorer.
2 Select the cluster_name > Monitor Manager > monitor_name > probe_name in the left
pane.
3 Select Probe > Delete or right-click the probe and select Delete.
Configuring JRun probes in UNIX
This section describes the following:
• “Adding JRun probes” on page 89
• “Editing and removing JRun probes” on page 91
88 Chapter 4 Configuring Clusters
Adding JRun probes
To add a new JRun probe:
1 In the ClusterCATS Web Explorer, click the Show Cluster link.
The Show Cluster page appears.
2 In the Web Server Name field, enter the fully qualified host name of a server for
which to configure the JRun probe.
3Click OK.
The Cluster Member List page appears.
4 Click the Server Attributes link.
The Connect To Server page appears.
5 Select a server to add a probe to from the Web Server Name list box.
6Click OK.
The selected server’s Properties page appears.
7 Click the JRun Probe link.
If there are probes for this server, the Probe List page appears:
8 To create a new probe, click New. The JRun Application Probe page appears.
If this is the first probe for this server, or you clicked New to add a probe, the JRun
Application Probe page appears:
Using JRun probes 89
9 Configure the application probe settings as described in the following table:
Field Description
Status This is an informational field. If the probe is not registered, the Status
displays Not registered. If the probe is registered, the Status displays
Succeeding.
Pathname Enter the path to the JRun probe. Do not change the default selection
unless you installed ClusterCATS for JRun to a directory other than
the default installation directory. The default is /usr/lib/btcats/
program/jrunprobe.
Wo rk in g
directory
Startup
Param eter s
Timeout (sec) Enter a time to indicate how long ClusterCATS waits before a JRun
Enter the path to the probe’s working directory. Do not change the
default selection unless you installed ClusterCATS for JRun to a
directory other than the default installation directory.
The default is /usr/lib/btcats/program/.
Enter parameters passed to the probe on execution, using the
following syntax:
URL success_string [RESTART|NORESTART|
<JRun_server>] [LOG|NOLOG]
URL — enter the actual URL of the page you want the probe to test. By
default, this is http://<your_server>/btauxdir/
jrunprobe.jsp. The probe opens the page and searches for the
success_string.
success_string — enter a text string that appears at the page
specified by the URL. If the success_string includes spaces, it must
be enclosed in quotation marks.
RESTART|NORESTART — enter RESTART to make the probe
automatically restart the default JRun server on a failure. Enter
NORESTART if you do not want ClusterCATS to restart the JRun
server on a failure. You can replace RESTART with the name of a
specific JRun server (such as default) to restart.
LOG|NOLOG — enter LOG to enable logging for the ClusterCATS
application probe or NOLOG to disable it. The probe logs are stored in
the /<CC_install_directory>/log/ directory.
The default for Startup Parameters is http://<your_server>/btauxdir/
jrunprobe.jsp Hello NORESTART NOLOG
server failure is registered.
Do not set this value to less than 60, because ClusterCATS might
restart the JRun server inadvertently (due to network congestion, for
example), rather than detect an actual failure on the JRun server.
90 Chapter 4 Configuring Clusters
Loading...