Configuration Guide For The BIG-IP Web Accelerator System

Configuration Guide for the BIG-IP WebAccelerator System
version 10.2
MAN-0251-04
Product Version
This manual applies to product version 10.2 of the BIG-IP WebAccelerator.
Publication Date
This manual was published on July 29, 2010.
Legal Notices
Copyright
Copyright 2008-2010, F5 Networks, Inc. All rights reserved. F5 Networks, Inc. (F5) believes the information it furnishes to be accurate and reliable. However, F5 assumes no responsibility for the use of this information, nor any infringement of patents or other rights of third parties which may result from its use. No license is granted by implication or otherwise under any patent, copyright, or other intellectual property right of F5 except as specifically described by applicable user licenses. F5 reserves the right to change specifications at any time without notice.
Trademarks
F5, F5 Networks, the F5 logo, BIG-IP, 3-DNS, Access Policy Manager, APM, Acopia, Acopia Networks, Application Accelerator, Ask F5, Application Security Manager, ASM, ARX, Data Guard, Edge Client, Edge Gateway, Enterprise Manager, EM, FirePass, FreedomFabric, Global Traffic Manager, GTM, iControl, Intelligent Browser Referencing, Internet Control Architecture, IP Application Switch, iRules, Link Controller, LC, Local Traffic Manager, LTM, Message Security Module, MSM, NetCelera, OneConnect, Packet Velocity, Protocol Security Module, PSM, Secure Access Manager, SAM, SSL Accelerator, SYN Check, Traffic Management Operating System, TMOS, TrafficShield, Transparent Data Reduction, uRoam, VIPRION, WANJet, WAN Optimization Module, WOM, WebAccelerator, WA, and ZoneRunner are trademarks or service marks of F5 Networks, Inc., in the U.S. and other countries, and may not be used without F5's express written consent. All other product and company names herein may be trademarks of their respective owners.
Patents
This product protected by U.S. Patent[s] 6,505,230; 6,640,240; 6,772,203; 6,970, 933; 7,113,962; and 7,114,180. Other patents pending.
Export Regulation Notice

This product may include cryptographic software. Under the Export Administration Act, the United States government may consider it a criminal offense to export this product from the United States.
RF Interference Warning
This is a Class A product. In a domestic environment this product may cause radio interference, in which case the user may be required to take adequate measures.
FCC Compliance
This equipment has been tested and found to comply with the limits for a Class A digital device pursuant to Part 15 of FCC rules. These limits are designed to provide reasonable protection against harmful interference when the equipment is operated in a commercial environment. This unit generates, uses, and can radiate radio frequency energy and, if not installed and used in accordance with the instruction manual, may cause harmful interference to radio communications. Operation of this equipment in a residential area is likely to cause harmful interference, in which case the user, at his own expense, will be required to take whatever measures may be required to correct the interference. Any modifications to this device, unless expressly approved by the manufacturer, can void the user's authority to operate this equipment under part 15 of the FCC rules.
Configuration Guide for the BIG-IP WebAcceleratorTM System
Canadian Regulatory Compliance

This Class A digital apparatus complies with Canadian ICES-003.
Standards Compliance
This product conforms to the IEC, European Union, ANSI/UL and Canadian CSA standards applicable to Information Technology products at the time of manufacture.
Acknowledgments
This product includes software developed by the University of California, Berkeley and its contributors. This product includes software developed by the Computer Systems Engineering Group at the Lawrence Berkeley Laboratory. This product includes software developed by the NetBSD Foundation, Inc. and its contributors. This product includes software developed by Christopher G. Demetriou for the NetBSD Project. This product includes software developed by Adam Glass. This product includes software developed by Christian E. Hopps. This product includes software developed by Dean Huxley. This product includes software developed by John Kohl. This product includes software developed by Paul Kranenburg. This product includes software developed by Terrence R. Lambert. This product includes software developed by Philip A. Nelson. This product includes software developed by Herb Peyerl. This product includes software developed by Jochen Pohl for the NetBSD Project. This product includes software developed by Chris Provenzano. This product includes software developed by Theo de Raadt. This product includes software developed by David Muir Sharnoff. This product includes software developed by SigmaSoft, Th. Lockert. This product includes software developed for the NetBSD Project by Jason R. Thorpe. This product includes software developed by Jason R. Thorpe for And Communications, http://www.and.com. This product includes software developed for the NetBSD Project by Frank Van der Linden. This product includes software developed for the NetBSD Project by John M. Vinopal. This product includes software developed by Christos Zoulas. This product includes software developed by Charles Hannum. This product includes software written by Steffen Beyer and licensed under the Perl Artistic License and the GPL This product includes software written by Makamaka Hannyaharamitu (C) 2007-2008. This product includes software developed by Charles Hannum, by the University of Vermont and State Agricultural College and Garrett A. Wollman, by William F. Jolitz, and by the University of California, Berkeley, Lawrence Berkeley Laboratory, and its contributors. This product includes software developed by the University of Vermont and State Agricultural College and Garrett A. Wollman. In the following statement, "This software" refers to the Mitsumi CD-ROM driver: This software was developed by Holger Veit and Brian Moore for use with "386BSD" and similar operating systems. "Similar operating systems" includes mainly non-profit oriented systems for research and education, including but not restricted to "NetBSD," "FreeBSD," "Mach" (by CMU). In the following statement, "This software" refers to the parallel port driver: This software is a component of "386BSD" developed by William F. Jolitz, TeleMuse. This product includes software developed by the Apache Group for use in the Apache HTTP server project (http://www.apache.org/). This product includes software developed by Darren Reed. ( 1993-1998 by Darren Reed). This product includes software licensed from Richard H. Porter under the GNU Library General Public License ( 1998, Red Hat Software), www.gnu.org/copyleft/lgpl.html.
ii
This product includes the standard version of Perl software licensed under the Perl Artistic License ( 1997, 1998 Tom Christiansen and Nathan Torkington). All rights reserved. You may find the most current standard version of Perl at http://www.perl.com. This product includes software developed by the University of California, Berkeley and its contributors. This product includes software developed by the Computer Systems Engineering Group at the Lawrence Berkeley Laboratory. This product includes software developed by the NetBSD Foundation, Inc. and its contributors. This product includes software developed by Christopher G. Demetriou for the NetBSD Project. This product includes software developed by Adam Glass. This product includes software developed by Christian E. Hopps. This product includes software developed by Dean Huxley. This product includes software developed by John Kohl. This product includes software developed by Paul Kranenburg. This product includes software developed by Terrence R. Lambert. This product includes software developed by Philip A. Nelson. This product includes software developed by Herb Peyerl. This product includes software developed by Jochen Pohl for the NetBSD Project. This product includes software developed by Chris Provenzano. This product includes software developed by Theo de Raadt. This product includes software developed by David Muir Sharnoff. This product includes software developed by SigmaSoft, Th. Lockert. This product includes software developed for the NetBSD Project by Jason R. Thorpe. This product includes software developed by Jason R. Thorpe for And Communications, http://www.and.com. This product includes software developed for the NetBSD Project by Frank Van der Linden. This product includes software developed for the NetBSD Project by John M. Vinopal. This product includes software developed by Christos Zoulas. This product includes software developed by Charles Hannum. This product includes software developed by Charles Hannum, by the University of Vermont and Stage Agricultural College and Garrett A. Wollman, by William F. Jolitz, and by the University of California, Berkeley, Lawrence Berkeley Laboratory, and its contributors. This product includes software developed by the University of Vermont and State Agricultural College and Garrett A. Wollman. In the following statement, "This software" refers to the Mitsumi CD-ROM driver: This software was developed by Holger Veit and Brian Moore for use with "386BSD" and similar operating systems. "Similar operating systems" includes mainly non-profit oriented systems for research and education, including but not restricted to "NetBSD," "FreeBSD," "Mach" (by CMU). In the following statement, "This software" refers to the parallel port driver: This software is a component of "386BSD" developed by William F. Jolitz, TeleMuse. This product includes software developed by the Apache Group for use in the Apache HTTP server project (http://www.apache.org/). This product includes software developed by Darren Reed. ( 1993-1998 by Darren Reed). This product includes software licensed from Richard H. Porter under the GNU Library General Public License ( 1998, Red Hat Software), www.gnu.org/copyleft/lgpl.html. This product includes the standard version of Perl software licensed under the Perl Artistic License ( 1997, 1998 Tom Christiansen and Nathan Torkington). All rights reserved. You may find the most current standard version of Perl at http://www.perl.com. This product includes software developed by Eric Young. Portions of the material included in Appendix C came from the Internet Software Consortium, http://www.isc.org/. Rsync was written by Andrew Tridgell and Paul Mackerras, and is available under the Gnu Public License. This product includes Malloc library software developed by Mark Moraes. ( 1988, 1989, 1993, University of Toronto).
iii
This product includes open SSL software developed by Eric Young (eay@cryptsoft.com), ( 1995-1998). This product includes open SSH software developed by Tatu Ylonen <ylo@cs.hut.fi>, Espoo, Finland ( 1995). This product includes open SSH software developed by Niels Provos ( 1999). This product includes SSH software developed by Mindbright Technology AB, Stockholm, Sweden, www.mindbright.se, info@mindbright.se ( 1998-1999). This product includes free SSL software developed by Object Oriented Concepts, Inc., St. John's, NF, Canada, ( 2000). This product includes software developed by Object Oriented Concepts, Inc., Billerica, MA, USA ( 2000). This product includes software developed by The Legion of the Bouncy Castle. Copyright (c) 2000 - 2009 The Legion Of The Bouncy Castle (http://www.bouncycastle.org)
iv
Table of Contents
Table of Contents
1
Getting Started
About the WebAccelerator system ...........................................................................................1-1 Managing your applications ..................................................................................................1-1 Monitoring traffic to your applications .............................................................................1-1 Deployment options for the WebAccelerator system .................................................1-2 Using the Configuration utility .....................................................................................................1-4 Accessing acceleration policies ....................................................................................................1-7 Reviewing the documentation set ...............................................................................................1-8 Finding help and technical support resources ..........................................................................1-9
2
Overview of the WebAccelerator System
Servicing requests to your origin web servers ........................................................................2-1 Processing HTTP requests and managing responses .....................................................2-2 Generating log files .........................................................................................................................2-5
3
Initial Configuration and Maintenance Tasks
Completing initial configuration for the Local Traffic Manager ............................................3-1 Completing initial configuration for the WebAccelerator system ......................................3-2 Defining an NTP server ........................................................................................................3-2 Creating the HTTP class profile .........................................................................................3-2 Configuring a virtual server and pool ................................................................................3-3 Creating an application profile ............................................................................................3-5 Completing optional configuration tasks ...................................................................................3-9 Processing unmapped requests ..........................................................................................3-9 Using the MultiConnect feature ...................................................................................... 3-10 Using a symmetric deployment ....................................................................................... 3-12 Performing maintenance tasks .................................................................................................. 3-17 Checking the WebAccelerator system processes ...................................................... 3-17 Changing the log file monitoring interval ...................................................................... 3-18
4
Changing Default Settings
Understanding object classification .............................................................................................4-1 Classifying by object type .....................................................................................................4-1 Classifying by group ...............................................................................................................4-1 Managing object types ...........................................................................................................4-2 Understanding URL normalization ..............................................................................................4-6 Managing URL normalization settings ...............................................................................4-7 Selectively disabling content-based identity .....................................................................4-8 Customizing options in the pvsystem.conf file ...................................................................... 4-10 Changing log file rotation parameters ............................................................................ 4-11 Changing TTL parameters for compiled responses .................................................... 4-12 Changing cookie encryption parameters ...................................................................... 4-13 Changing default values for HDS prune ........................................................................ 4-14
5
Troubleshooting and Monitoring
Using performance reports ..........................................................................................................5-1 Using error and status log files ....................................................................................................5-3 Configuration Guide for the BIG-IP WebAcceleratorTM System vii
Table of Contents
tomcat ......................................................................................................................................5-3 intelligence interface ..............................................................................................................5-3 pvac ...........................................................................................................................................5-3 Using system log files .....................................................................................................................5-4 Resolving communication system failures .................................................................................5-5 Using X-PvInfo response headers ...............................................................................................5-6 Invalidating and clearing the WebAccelerator systems cache .............................................5-7
Glossary Index
viii
1
Getting Started
About the WebAccelerator system Using the Configuration utility Accessing acceleration policies Reviewing the documentation set Finding help and technical support resources
Getting Started
About the WebAccelerator system

The BIG-IP WebAccelerator system is a delivery solution designed to improve the speed at which users access your web applications (such as Microsoft SharePoint, Microsoft Outlook Web Access, BEA AquaLogic, SAP Portal, Oracle Siebel CRM, Oracle Portal, and others) and wide area network (WAN). The WebAccelerator system does this through acceleration policy features that modify web browser behavior, as well as compresses and caches dynamic and static content, which decreases bandwidth usage and ensures that your users get the most quick and efficient access to your web applications and WAN. These processes, and deployment options, are discussed in the following sections. For more specific information about the how the WebAccelerator system manages access to your web applications, see Chapter 2, Overview of the WebAccelerator System. The BIG-IP WebAccelerator system is one of several products that constitute the BIG-IP product family. All BIG-IP products run on the Traffic Management Operating System, commonly referred to as TMOS. For an overview of the complete BIG-IP product offering, see the Introduction to the BIG-IP System chapter of the TMOS Management Guide for BIG-IP Systems.
Managing your applications

To accelerate access to your applications, the WebAccelerator system uses acceleration policies that use a proprietary language to manipulate HTTP responses from origin web servers. After the WebAccelerator system manipulates the HTTP responses using its Rewrite Engine, it processes the responses. Therefore, the WebAccelerator system processes manipulated responses, rather than the original responses that are sent by the origin web servers.
Note
For information about how to create customized rewrite scripts, contact F5 Networks Technical Support.
Monitoring traffic to your applications

In addition to the using the acceleration policy features, you can easily monitor your HTTP traffic and system processes through monitoring tools. For more information about monitoring the WebAccelerator system processes and traffic, see Chapter 5, Troubleshooting and Monitoring.
1-1
Chapter 1
Deployment options for the WebAccelerator system

There are two basic deployment options for the WebAccelerator system. Asymmetric Symmetric An asymmetric deployment consists of one or more WebAccelerator systems installed on one end of a WAN, and in the same location as the origin web servers that are running the applications to which the WebAccelerator system is accelerating client access. Figure 1.1 illustrates an asymmetric deployment with a single WebAccelerator system on one end of a WAN.
Figure 1.1 Asymmetric deployment example
A symmetric deployment is composed of sets of two WebAccelerator systems: a central WebAccelerator system and a remote WebAccelerator system. These WebAccelerator systems are located on opposite ends of a WAN. Figure 1.2, on page 1-3 illustrates a symmetric deployment with multiple WebAccelerator systems located in remote offices.
1-2
Getting Started
Figure 1.2 Symmetric deployment example
In a symmetric deployment, the central WebAccelerator system is installed closest to the origin web servers running the applications to which the WebAccelerator system is accelerating client access. The remote WebAccelerator system is installed close to the clients, which can be in a separate geographic site around the world or across the country. You can deploy any number of WebAccelerator systems in any combination of configurations, including a simultaneous configuration of asymmetric and symmetric deployments. This flexibility gives you the freedom to choose the most appropriate WebAccelerator system deployment for your environment, guaranteeing that all clients requesting information are getting the fastest possible access. For specific information about how to deploy an optional symmetric deployment, see Configuring a symmetric deployment, on page 3-13.
1-3
Chapter 1
Using the Configuration utility

The Configuration utility is the browser-based graphical user interface that provides you access to the WebAccelerator systems configuration options, as well as the configuration options for the network, system, and local traffic. From the Help tab, you can access context-sensitive information about the controls and settings located on each on each screen.
To access the Configuration utility

1. Open a web browser. 2. In the address box, type a URL that includes the management IP address of the BIG-IP device, as follows:
https://<mgmt_IP_address>
For example, if the management IP address of the BIG-IP device is 192.168.168.102, type https://192.168.168.102 in the address box. 3. Type a valid user name and password. 4. Click OK.
Figure 1.3, on page 1-5 shows an example of the Welcome screen for the Configuration utility. The modules displayed depend on your software licenses.
Important
All users need to use the web-based Configuration utility to license the system for the first time. For the most current list of the supported browsers for the Configuration utility, refer to the current WebAccelerator system release note at https://support.f5.com.
1-4
Getting Started
Figure 1.3 Welcome screen for the Configuration utility
The Configuration utility contains the following components:
The identification and messages area This area, above the navigation pane, the menu bar, and the body, is where you find the system identification, including the host name, and management IP address. This area also displays certain system messages. The navigation pane This area, located on the left side of the screen, contains the Main tab, the Help tab, and the About tab. The Main tab provides links to the major configuration objects for the various modules. The Help tab provides context-sensitive help for each screen in the Configuration utility. The About tab provides a quick way to locate information about Setup, Support, Plugins, and Download system options.
1-5
Chapter 1
The menu bar Located below the identification and messages area, and above the body, the menu bar provides links to configuration objects within each major object. The body Located in the center of the screen, the body displays configuration settings.
1-6
Getting Started
Accessing acceleration policies

An acceleration policy is a collection of matching rules and acceleration rules that determine how the WebAccelerator system manages and responds to HTTP requests to your web applications. The Policies screen displays all of the acceleration policies available for assignment to your applications.
To access the Policies screen

In the navigation pane, expand WebAccelerator and click Policies. The Policies screen displays a list of existing acceleration policies.
Figure 1.4 Example Policies screen
From the Policies screen, you can access additional screens, from which you can perform additional tasks. For more information about managing acceleration policies, see the Policy Management Guide for the BIG-IP WebAcceleratorTM System.
1-7
Chapter 1
Reviewing the documentation set

The WebAccelerator system documentation set consists of the following items: Configuration Guide for the BIG-IP WebAcceleratorTM System Describes the core product concepts and provides the procedures for configuring and monitoring the WebAccelerator system. Policy Management Guide for the BIG-IP WebAcceleratorTM System Provides information about creating and editing policies to tailor the WebAccelerator system for optimal performance. Release notes Provide information about new features, fixes, known issues, and workarounds. Online help Provides context-sensitive description of each control and setting on each screen. Additionally, you must review specific chapters in the following guides: BIG-IP Systems: Getting Started Guide For information about performing the required configuration for the BIG-IP Local Traffic ManagerTM, as well as information about installing, enabling, and configuring resource provisioning for the WebAccelerator system license. Configuration Guide for BIG-IP Local Traffic Manager For information about how to define a virtual server and pool. TMOS Management Guide for BIG-IP Systems For an overview of the complete BIG-IP product offering.
1-8
Getting Started
Finding help and technical support resources

You can find technical documentation and product information using the following resources: Welcome screen in the Configuration utility The Welcome screen in the Configuration utility contains links to many useful web sites and resources, including: The F5 Networks Technical Support web site The F5 Solution Center The F5 DevCentralSM web site Plug-ins, SNMP MIBs, and SSH clients. Online help The WebAccelerator system provides context-sensitive online help for each screen. The online help contains descriptions of each control and setting on the screen. To access the online help, click the Help tab on the left navigation pane of the Configuration utility. F5 Networks Technical Support web site The F5 Networks Technical Support web site provides the latest documentation set for the product, including: Release notes, current and past Software and hardware guides, current and past (in PDF and HTML format) Technical notes The Ask F5SM Knowledge Base To access the F5 Networks Technical Support web site, you need to register at https://support.f5.com.
1-9
Chapter 1
1 - 10
2
Servicing requests to your origin web servers Generating log files
Servicing requests to your origin web servers

Most sites are built on a collection of web servers, application servers, and database servers that we refer to collectively as origin web servers. The BIG-IP WebAcceleratorTM system is installed on your network between the users of your applications and the origin web servers on which the applications run, and accelerates your applications response to HTTP requests. Origin web servers can serve all possible permutations of content, while the WebAccelerator system only stores and serves page content that clients have previously requested from your site. By transparently servicing the bulk of common requests, the WebAccelerator system significantly reduces the load on your origin web servers, which improves performance for your site. Once installed, the WebAccelerator system receives all requests destined for the origin web server. When a client makes an initial request for a specific object, the WebAccelerator system relays the request to the origin web server, and caches the response that it receives in accordance with the policy, before forwarding the response to the client. The next time a client requests the same object, the WebAccelerator system serves the response from its cache, based on lifetime settings within the policy, instead of sending the request to the origin web servers. This means that, for each HTTP request it receives, the WebAccelerator system performs one of the following actions:
Services the request from its cache Upon receiving a request from a browser or web client, the WebAccelerator system initially checks to see if it can service the request from compiled responses in its cache. Sends the request to the origin web servers If the WebAccelerator system is unable to service the request from its cache, it sends a request to the origin web server. Once it receives a response from the origin web server, the WebAccelerator system caches that response according to the associated acceleration policy rules, and then forwards the request to the client. Relays the request to the origin web servers The WebAccelerator system relays requests directly to the origin web server, for some predefined types of content, such as requests for streaming video. Creates a tunnel to send the request to the origin web servers For any encrypted traffic (HTTPS) content that you do not want the WebAccelerator system to process, you can use tunneling. Note that the WebAccelerator system can cache and respond to SSL traffic without using tunnels.
2-1
Chapter 2
During the process of application matching, the WebAccelerator uses the information in the HTTP request to match the request to an application profile that you created. Once matched to an application profile, the WebAccelerator system applies the associated acceleration policys matching rules in order to group the request and response to a specific leaf node on the Policy Tree. The WebAccelerator system, then applies the acceleration policys acceleration rules to each group. These acceleration rules dictate how the WebAccelerator system manages the request. To perform the processes required to manage requests, the WebAccelerator system uses the following services: Communications server This service manages the communications between all WebAccelerator system processes. HDS prune This service manages the on-disk cache and removes compiled responses that are no longer needed. For more information about HDS prune, see Changing default values for HDS prune, on page 4-14. pvac This service manages HTTP traffic in accordance with the options defined in the associated acceleration policy. waicd This service manages the communications between peer WebAccelerator systems in a symmetric deployment. For information about how to monitor these services, see Checking the WebAccelerator system processes, on page 3-17.
Processing HTTP requests and managing responses

The first time that a WebAccelerator system receives new content from the origin web server in response to an HTTP request, it processes the information as follows, before returning the requested object (response) to the client:
Compiles an internal representation of the object The WebAccelerator system uses compiled responses received from the origin web server, to assemble an object in response to an HTTP request. Assigns a Unique Content Identifier (UCI) to the compiled response, based on elements present in the request The origin web server generates specific responses based on certain elements in the request, such as the URI and query parameters. The WebAccelerator system includes these elements in a UCI that it creates, so that it can easily match future requests to the correct content in its cache. The WebAccelerator system matches content to the UCI for both the request and the compiled response that it created to service the request.
2-2
The WebAccelerator system processes requests and responses in a general sequential pattern, as illustrated in Figure 2.1.
Figure 2.1 Request/Response flow
Each step is defined as follows. 1. Clients, using web browsers, request pages from your site. From the clients perspective, they are connecting directly to your site; they have no knowledge of the WebAccelerator system. 2. The WebAccelerator system examines the clients request to determine if it meets all the HTTP requirements needed to service the request. If the request does not meet the HTTP requirements, the WebAccelerator system issues an error to the client. (For information about what the WebAccelerator system requires to service a request, see the Policy Management Guide for the BIG-IP WebAccelerator System.) 3. The WebAccelerator system examines the request elements and creates a UCI, and then reviews its cache to see if it has a compiled response stored under that same UCI.
2-3
Chapter 2
If the content is being requested for the first time (there is no matching compiled response in the WebAccelerator systems cache), the WebAccelerator system uses the host map to relay the request to the appropriate origin web server to get the required content. If content with the same UCI is already stored as a compiled response in the WebAccelerator systems cache, the WebAccelerator system checks to see if the content has expired. If the content has expired, the WebAccelerator system checks to see if the information in its cache still matches the origin web server. If it does, the WebAccelerator system moves directly to step 7. Otherwise, it performs the following step. 4. The origin web server either responds or queries the application servers or databases content. 5. The application servers or databases provide the input back to the origin web server. 6. The origin web server replies to the WebAccelerator system with the requested material, and the WebAccelerator system compiles the response. If the response meets the appropriate requirements, the WebAccelerator system stores the compiled response in its cache under the appropriate UCI. (For more information about HTTP response requirements see the Policy Management Guide for the BIG-IP WebAccelerator System.) 7. The WebAccelerator system uses the compiled response, and any associated assembly rule parameters, to recreate the page. The assembly rule parameters dictate how to update the page with generated content. (For information about assembly rules, see the chapter, Configuring Assembly Rules, in the Policy Management Guide for the BIG-IP WebAccelerator System.) 8. The WebAccelerator system directs the response to the client.
2-4
Generating log files

The WebAccelerator system generates two types of system log files:
Change logs These logs are used to pass data between WebAccelerator system processes and to populate the content displayed in the Performance Reports. For information about Performance Reports, see Using performance reports, on page 5-1. Hit logs These logs contain the same type of information as the HTTP web server log files. Hit logs are disabled by default. For information about how to enable customize the content for the hit logs, see the chapter, Specifying Log Formats, in the Policy Management Guide for the BIG-IP WebAccelerator System.
By default, the WebAccelerator system monitors these log files on an hourly basis and rotates the log when it reaches 10MB. For information about how to modify these parameters, see Changing the log file monitoring interval, on page 3-18 and Changing log file rotation parameters, on page 4-11.
2-5
Chapter 2
2-6
3
Completing initial configuration for the Local Traffic Manager Completing initial configuration for the WebAccelerator system Completing optional configuration tasks Performing maintenance tasks
Completing initial configuration for the Local Traffic Manager

Before you configure the WebAccelerator system, you must complete the following tasks on the BIG-IP Local Traffic Manager. Install, activate, and configure resource provisioning for the WebAccelerator license. Configure general network settings. Configure name resolution (DNS or entries to the host file). If you have not yet completed the required configuration on the BIG-IP Local Traffic Manager, refer to the BIG-IP Systems: Getting Started Guide, the Configuration Guide for BIG-IP Local Traffic Manager, and the TMOS Management Guide for BIG-IP Systems for additional information. These guides are available on the Technical Support web site, https://support.f5.com. After you perform these configuration tasks on the BIG-IP Local Traffic Manager, you then perform the initial configuration tasks for the WebAccelerator system as outlined in the next section, Completing initial configuration for the WebAccelerator system, on page 3-2.
Important
On the WebAccelerator 4500 platform, resource provisioning is set by default, and you simply perform the initial Setup utility procedures to access the WebAccelerator systems navigation menu.
3-1
Chapter 3
Completing initial configuration for the WebAccelerator system

After you have performed the initial configuration tasks on the BIG-IP Local Traffic Manager, you can begin configuration for the WebAccelerator system, by: Defining an NTP server Creating an HTTP class profile Configuring a virtual server and pool on the BIG-IP Local Traffic Manager Creating an application profile
Defining an NTP server

Network Time Protocol (NTP) synchronizes the clocks on your network with a defined NTP server. This synchronization ensures that the WebAccelerator system properly maintains its cache, and synchronizes configuration changes for optional symmetric deployments.
To define an NTP server

1. In the navigation pane, expand System and click Configuration. The Device, General properties screen displays BIG-IP system properties and operations. 2. From the Device menu, choose NTP. The Device, NTP properties screen displays the NTP properties. 3. In the Address box, type an address for the NTP server. 4. Click Add. 5. Click Update.
Creating the HTTP class profile

The HTTP class profile uses the HTTP header, cookie, host, and path, and other HTTP items to classify traffic in order to accelerate traffic for applications that are running on a virtual server.
To create the HTTP class profile

1. In the navigation pane, expand WebAccelerator and click Class Profiles. The Class Profiles screen displays the WebAccelerator class profiles and their status.
3-2
2. Click Create. The Class Profiles, New HTTP Class screen displays the properties, configuration, and actions settings for a class profile. 3. In the Name box, type a name for the HTTP class profile. For example, SEAWebAccelerator. 4. From the Parent Profile list, select httpclass. 5. In the Configuration area, verify that WebAccelerator setting is set to Enabled. Leave all other settings at Match all. 6. Click Finished.
WARNING
The HTTP class profile exists in both the WebAccelerator and the Local Traffic sections of the Configuration utility. In the WebAccelerator section of the Configuration utility, the WebAccelerator system is enabled by default. In the Local Traffic section of the Configuration utility, you must select the Custom check box and explicitly enable WebAccelerator. If you create the HTTP class profile from the Local Traffic section and you do not enable the WebAccelerator system, you effectively disable web acceleration for the associated virtual server.
Configuring a virtual server and pool

The virtual server processes and routes incoming traffic in accordance with the settings that you configure in the associated HTTP class profile. The pool hosts the application for which you want the WebAccelerator system to accelerate traffic, using the application profiles acceleration policy.
Note
The following procedure outlines only the basic virtual server and pool configuration. For detailed information about virtual servers, pools, and the other local traffic components, refer to the Configuration Guide for BIG-IP Local Traffic Manager on the Ask F5 Technical Support web site, https://support.f5.com.
To configure a virtual server and pool

1. In the navigation pane, expand Local Traffic, and then click Virtual Servers. The Virtual Servers: Virtual Server List screen displays a list of existing virtual servers. 2. Click Create. The Virtual Servers: Virtual Server List, New Virtual Server screen displays the properties, configuration, and resources settings for a virtual server. 3. In the Name box, type a name for the virtual server.
3-3
Chapter 3
4. For the Destination Type, click Host and type an IP address in the Address box. 5. In the Service Port box, type the appropriate service port for your application. For example, for HTTP, the port is 80. Alternatively, you can select a service type from the list. 6. Select Enabled from the State list. 7. Select http-acceleration from the HTTP Profile list. Important: We strongly recommend that you leave RAM Cache enabled for the http-acceleration profile and that you do not make any modifications to the RAM Cache default settings for Minimum Object Size, Maximum Object Size, URI Caching, and Ignore Headers, as it will adversely affect the way the BIG-IP WebAccelerator system manages HTTP traffic for your site. 8. From the Configuration list, select Advanced. 9. Check Enabled next to Port Translation. Important: If Port Translation is disabled for the virtual server, the WebAccelerator system cannot properly accelerate traffic. 10. In the Resources section, select the WebAccelerator-enabled HTTP class profile from the HTTP Class Profiles Available list, and click the Move button (<<) to add the profile to the Enabled list. 11. Next to the Default Pool list, click the Add (+) button. 12. In the Name box, type a name for the pool. 13. For Health Monitors, select http from the Available list and click the Move button (<<) to add the monitor to the Active list. 14. In the Resources section, select a Load Balancing Method from the list. 15. Leave Priority Group Activation set to Disabled. 16. Into the Address and Port boxes, type the address and port for the pool members. 17. Click Add. 18. Click Finished. The screen refreshes and opens the New Virtual Server screen, where you see the new pool in the Default Pool list. 19. Click Finished again. The virtual server that you created displays.
3-4
Creating an application profile

The application profile provides the key information that the WebAccelerator system needs to appropriately handle requests to your sites web applications. Before you can create the application profile, you must complete the following tasks: Define your host map Choose an acceleration policy
Defining your host map

When the WebAccelerator system receives an HTTP request, it compares the host on the request to those in its host map to determine which application profile to apply. Once it matches to an application profile, it can use the associated acceleration policy you assigned to handle the request. When you create a host map, you identify the domain as it appears on the HTTP Host request header. These domains are called requested hosts. When you specify the host name for the requested host in a host map, you can use a wildcard, an asterisk (*) followed by a period, for the first character in the domain. This wildcard can represent one or more subdomains, enabling you to map several subdomains to one origin web server in one step. Using a wildcard saves time if your site has several subdomains. Following are examples of valid requested host names that use wildcards.
*.sales.siterequest.com maps to the following (all to the same destination host): direct.sales.siterequest.com marketing.sales.siterequest.com marcom.marketing.sales.siterequest.com
*siterequest.com maps to the following (all to the same destination host): www.siterequest.com engineering.siterequest.com direct.sales.siterequest.com marketing.sales.siterequest.com marcom.marketing.sales.siterequest.com
*.com maps all incoming requests that end in .com to one destination host. * maps all incoming requests to one destination host.
If the WebAccelerator system can map multiple requested host names to a request, it chooses the host name that most closely matches the request. Consider the following defined host names: a.com
Configuration Guide for the BIG-IP WebAcceleratorTM System 3-5
Chapter 3
www.a.com *.b.a.com *.a.com If the WebAccelerator system receives requests that contain these URLs, it maps to the requested hosts as follows: A request to www.a.com maps to www.a.com, and does not map to *.a.com. A request to a.com maps to a.com. Requests to c.a.com and b.a.com both map to *.a.com. A request to c.b.a.com maps to *.b.a.com.
WARNING
If the WebAccelerator system is not managing all of the traffic to the hosts, do not use a wildcard.
Choosing an acceleration policy

You may select a predefined acceleration policy that is associated with your specific application publisher or you may use one of the two predefined general delivery acceleration policies. Both work well for most sites that use Java 2 Platform Enterprise Edition (J2EE) applications. Level 1 Delivery This predefined acceleration policy is compliant with HTML version 2.0. For this acceleration policy, the WebAccelerator system: Sends all requests for HTML pages to the origin web server for content. Ignores any no-cache directives included in HTTP Cache-Control request headers, and uses the cache response directives that it receives from the origin web server. Level 2 Delivery This predefined acceleration policy is compliant with HTML version 3.0 and later. For this acceleration policy, the WebAccelerator system: Caches HTML pages and assigns a lifetime setting of 0, which prompts the WebAccelerator system to provide fresh content by making subsequent requests for that content, using a conditional GET. Uses the Intelligent Browser Referencing feature only for documents and includes. Ignores any no-cache directives included in HTTP Cache-Control request header, and uses the cache response directives that it receives from the origin web server. After you have planned your host map and chosen an acceleration policy, create the application profile using the following procedure.
3-6
To create an application profile

1. In the navigation pane, expand WebAccelerator and click Applications. The Applications screen displays a list of existing applications and associated policies. 2. Click Create. The Applications, New Application screen displays options, policies, and hosts settings for an application. 3. In the Application Name box, type a name for the application. 4. In the Description box, type an optional description. 5. From the Central Policy list, select the acceleration policy that you want the WebAccelerator system to use when requesting information from the associated application. If you have configured an optional symmetric deployment, we recommend that you select the predefined acceleration policy called, Symmetric Deployment, because it is specifically designed to manage content assembly in a symmetric deployment. For more information, see Using a symmetric deployment, on page 3-12. 6. If you have configured an optional symmetric deployment, from the Remote Policy list, select an acceleration policy for the remote WebAccelerator system. We recommend that you select the predefined acceleration policy, Symmetric Deployment. If you do not have a symmetric deployment, do not select a remote policy. 7. Optionally, from the Destination Host list, select a user-defined destination host. This setting displays only if you have configured an additional destination host. 8. In the Hosts section at the bottom of the screen, click the Add Host button. 9. In the Requested Host box, type a valid host name for each client host that you want to allow access to the application. 10. Click Save.
Verifying the application profile

After you create an application profile, you must verify that the WebAccelerator system is able to properly send data to and receive data from the origin web servers.
To verify the application profile

1. On a machine separate from the WebAccelerator system, and from which you can run a web browser, open the hosts file and add the host name that you used to access the web site application. The host name must point to the IP address for the virtual server that you configured.
3-7
Chapter 3
Note: On Microsoft Windows 2000 and Windows XP machines, the hosts file is located at C:\WINDOWS\system32\drivers\etc\hosts For example, if you can access the web site at the www.siterequest.com domain and the virtual server is at IP address 11.1.11.3, add the following line to the hosts file on the machine running the browser:
11.1.11.3 www.siterequest.com
All network traffic from the web browser machine for www.siterequest.com subsequently goes to the virtual server. 2. Request a page from www.siterequest.com. You should see the page that you would have received if your browser had accessed the origin web servers directly. If the browser times out the request, it means that either the WebAccelerator system is not running, or the firewall is blocking access to port 80 on the WebAccelerator system. 3. If you receive an Access denied by intermediary error, perform the following tasks: Verify that the hosts file is correct. Verify that the host map for the application profile is correct. Verify that you used a domain in the request that matches a requested host in the host map, and that it maps to the destination host. 4. After you verify the application profile and confirm that the host mapping is correct, remove any entries that you changed or added.
3-8
Completing optional configuration tasks

After you complete the essential configuration tasks, you can further customize by configuring the WebAccelerator system to: Process unmapped requests Use MultiConnect Accelerate requests in a symmetric deployment
Note
In addition to the optional configuration tasks noted here, you can also create a user-defined acceleration policy or import a signed acceleration policy. For more information, refer to the Policy Management Guide for the BIG-IP WebAccelerator System.
Processing unmapped requests

A request for a domain that is not listed in the requested host map is called an unmapped request. If you create an application policy that is based on a host name that is not identified in a host map, you will have an unmapped host map. By default, the WebAccelerator system replies to clients that request unmapped hosts with an HTTP 403 response code. F5 Networks recommends that you reconcile unmapped requests by adding the host name to the host map for the applications that are using the specified application profile. Another option is to allow the WebAccelerator system to process unmapped requests, instead of responding with an error; however, the following security implication is associated with processing unmapped requests.
Security implication
If you configure the WebAccelerator system to process unmapped requests and you do not specify a proxy server, you enable the WebAccelerator system to act as a relay. F5 Networks recommends that you do not enable unmapped request processing unless your network meets one of the following conditions. Both the WebAccelerator system and the origin web server are on a private and secure network. You specify a proxy server to forward the unmapped requests to, as described in step 4 of the following procedure, and you configure that proxy server to properly manage unwanted or unsanctioned requests.
To enable unmapped request processing

1. In the navigation pane, expand WebAccelerator and click Unmapped hosts. The Unmapped Hosts screen displays a setting to process unmapped hosts.
Configuration Guide for the BIG-IP WebAcceleratorTM System 3-9
Chapter 3
2. Select the Process requests for unmapped hosts check box. The screen refreshes and displays additional options. 3. From the Policy list, select an acceleration policy for which you want to process unmapped requests. 4. To forward unmapped host requests to a specific proxy server, select the check box next to Forward unmapped host requests to a proxy server in the Forward Proxy Options area, and type an address in the Server Address box. 5. Click Save.
Using the MultiConnect feature

Most browsers create a limited number of TCP connections when requesting data. You can achieve faster data downloads by using the WebAccelerator systems MultiConnect feature, which modifies embedded URLs with unique subdomains, prompting the browser to open more simultaneous TCP connections. When MultiConnect is enabled, it prompts the clients web browser to open additional TCP connections to the WebAccelerator system for each subdomain when requesting pages over the HTTP protocol. The origin web servers never get a request from these additional subdomains; the additional subdomains are used exclusively on embedded URLs or links that request images or scripts and are only for requests and/or responses between the client and the WebAccelerator system. The WebAccelerator system uses the MultiConnect feature only on the following types of links. Image tags: <img src=...> Script tags: <script src=...> Forms whose input type is an image: <form><input type=image src=...></form> The MultiConnect feature is best suited for sites that have a high number of first-time visitors who are downloading a large number of images or scripts. F5 Networks recommends that you use this feature only if you have high-bandwidth links, because the additional TCP connections also increase the amount of traffic your site must manage. To use this feature, you must first perform the following tasks: Configure DNS with entries for the additional subdomains. Map the additional DNS entries to the same IP address as the base origin web server (for example, www.siterequest.com). Assign specific prefixes to the additional subdomains. For example, if the requested host for the mapping is www.siterequest.com, and you request two additional subdomains for the HTTP protocol, you assign a subdomain prefix of wa.
3 - 10
Construct a trusted SSL certificate that lists the additional subdomains that you created, as Subject Alternative Name entries. (This task is required only if you are configuring MultiConnect for use with HTTPS.) Once you perform these tasks, the WebAccelerator system changes the domain on qualifying embedded URLs and links so that they use the domains you specified. For example: wa1.www.siterequest.com wa2.www.siterequest.com
Important
Some client browsers close HTTPS connections to one domain before opening HTTPS connections to a new domain. This type of browser behavior can decrease the speed of access to applications for which the MultiConnect feature is enabled; therefore, F5 Networks recommends that you do not enable the MultiConnect feature for HTTPS connections.
To configure subdomains for the MultiConnect feature

1. In the navigation pane, expand WebAccelerator and click Applications. The Applications screen displays a list of existing applications and associated policies. 2. Click the name of the application for which you want to configure the MultiConnect feature. 3. In the Hosts area at the bottom of the screen, click the Options link next to the Requested Host box for which you want to configure MultiConnect. 4. From the HTTP Subdomains and HTTPS Subdomains lists, select the number of subdomains that you want the WebAccelerator system to generate for each protocol. 5. In the Subdomain Prefix box, type a prefix or leave it at the default of wa. 6. Click Save.
Important
If you are configuring MultiConnect for use with HTTPS, you must also construct a trusted SSL certificate that lists the additional subdomains that you created as Subject Alternative Name entries. If you are configuring MultiConnect for use with only HTTP, this step is not necessary. For more specific information about specifying Subject Alternative Name entries, contact your certificate authority. After you map the additional subdomains and construct a trusted SSL certificate with the Subject Alternative Name entries (Subject Alternative Name entries are required only for HTTPS connections), you can enable the
3 - 11
Chapter 3
MultiConnect feature for a specific acceleration policies as described in Chapter 8, Assembly Rules, of the Policy Management Guide for the BIG-IP WebAccelerator System.
Using a symmetric deployment

An optional configuration for a site with multiple WebAccelerator systems is a symmetric deployment. A symmetric deployment consists of central and remote WebAccelerator systems that have synchronized configurations. With this configuration, users can transparently utilize the functionality of a WebAccelerator system on another network across town, or across the globe, from both sides of the transaction as illustrated in Figure 3.1.
Figure 3.1 Symmetric deployment example
In a symmetric deployment, the central WebAccelerator system is the WebAccelerator system that is closest to the application it is accelerating. The central WebAccelerator system is accessed by local clients as well as clients from a remote WebAccelerator system located in a separate geographic location, which can be around the world or across the country. For example, say you have a WebAccelerator system located at a corporate office in North America that is accelerating a web mail server application that employees in a satellite office in Europe use. For this symmetric
3 - 12
deployment, the central WebAccelerator system is located at the corporate office, closest to the web mail application, and the remote WebAccelerator system is the WebAccelerator system in Europe. In this example, the satellite office employee sends an email request to his local WebAccelerator system in Europe, which responds to the request, or, if new content is required, sends the request to the central WebAccelerator system located in the corporate office in North America. The central WebAccelerator system responds to the request, or, if new content is required, sends the request to the origin web mail server. The central WebAccelerator system then caches the response and responds to the remote WebAccelerator system in Europe. Once the remote WebAccelerator system in Europe receives the response from the central WebAccelerator system in North America, it caches that response and then sends it to the employee. As long as the content is still valid, the remote WebAccelerator system in Europe can then respond to future requests for the same content from local clients.
Note
To monitor the status of an origin web server in a symmetric deployment, you must do so through the BIG-IP Local Traffic Manager systems http monitor only on the central WebAccelerator system. For more information about configuring and using http monitors, see the Configuration Guide for BIG-IP Local Traffic Manager.
Configuring a symmetric deployment

To configure a symmetric deployment, you must: Configure one or more central WebAccelerator systems and one or more remote WebAccelerator systems. Manually exchange SSL certificates between the systems.
Important
An NTP server is required to properly maintain the WebAccelerator systems cache and to synchronize changes among the systems in a symmetric deployment. Before you perform the following procedure, you must define an NTP server for the WebAccelerator systems on which you are configuring the symmetrical deployment. For information about defining an NTP server, see Defining an NTP server, on page 3-2. All members of a symmetric deployment are peers. Therefore, after you perform the initial configuration and manually exchange SSL certificates between the systems, subsequent changes that you make to any member propagate immediately to all other members of the symmetric deployment. This propagation happens regardless of whether the member you made a change to is a central or remote WebAccelerator system.
3 - 13
Chapter 3
Keep in mind that you must have at least one designated central WebAccelerator system at all times. In other words, you cannot delete or change the role of a central WebAccelerator system unless you have another central WebAccelerator system configured.
WARNING
In a symmetric deployment, the remote and central WebAccelerator systems communicate over port 4353 and exchange SSL certificates over port 22. If a firewall exists between these systems, you must modify its configuration so that port 4353 and port 22 are open. If you fail to open these ports, the central and remote WebAccelerator systems cannot properly exchange SSL certificates or synchronize. The first step to creating a symmetric deployment is to configure a central WebAccelerator system.
To configure a central WebAccelerator system

Important
When you configure a symmetric deployment, you must use external self IP addresses for the central and remote WebAccelerator systems. To find the external facing self IP address for each WebAccelerator system, use the b self command. 1. In the navigation pane, expand WebAccelerator, and then click Symmetric Deployment. The Symmetric Deployment screen displays lists of existing central and remote WebAccelerator systems. 2. Click Create. The Symmetric Deployment, New Symmetric Deployment screen displays settings to configure a central WebAccelerator system. 3. In the Name box, type a name for the central WebAccelerator system. 4. If the WebAccelerator system uses network address translation (NAT) to communicate with other WebAccelerator systems in the data center, select the Use NAT Support check box. If the WebAccelerator system does not use NAT, skip to step 7. 5. In the Global Address box, type the public IP address that the WebAccelerator system uses to communicate with computers outside of the data center. 6. In the Internal Address box, type the IP address that the WebAccelerator system uses to communicate with other WebAccelerator systems within the data center. Skip to step 8. 7. In the IP Address box, type the static self IP address for the central WebAccelerator system. This is the external facing (non-floating) self IP address for the central system.
3 - 14
8. For the Role setting, select the Central check box. 9. From the Data Center list, select a data center or leave it at the Default Data Center. Alternatively, select Add a New Data Center and type a new data center name in the associated box. 10. Click Save.
After you configure a central WebAccelerator system for the symmetric deployment, you can create one or more remote WebAccelerator systems.
To configure a remote WebAccelerator system

Important
When you configure a symmetric deployment, you must use external self IP addresses for the central and remote WebAccelerator systems. To find the external facing self IP address for each WebAccelerator system, use the b self command. 1. On the Symmetric Deployment screen, click Create. The Symmetric Deployment, New Symmetric Deployment screen displays settings to configure a remote WebAccelerator system. 2. In the Name box, type a name for the remote WebAccelerator system. 3. If the WebAccelerator system uses network address translation (NAT) to communicate with other WebAccelerator systems in the data center, select the Use NAT Support check box. If the WebAccelerator system does not use NAT, skip to step 6. 4. In the Global Address box, type the public IP address that the WebAccelerator system uses to communicate with computers outside of the data center. 5. In the Internal Address box, type the IP address that the WebAccelerator system uses to communicate with other WebAccelerator systems within the data center. Skip to step 7. 6. In the IP address box, type the static self IP address for the remote WebAccelerator system. This is the external facing (non-floating) self IP address for the remote system. 7. Select the Remote check box. 8. From the Data Center list, select a data center or leave it at Default Data Center. Alternatively, select Add a New Data Center and type a new data center name in the associated box. 9. Click Save.
3 - 15
Chapter 3
To view or modify a WebAccelerator system in a symmetric deployment

1. In the navigation pane, expand WebAccelerator, and click Symmetric Deployment. The Symmetric Deployment screen displays lists of existing central and remote WebAccelerator systems. 2. Click the name of a WebAccelerator system to view or change its configuration details. 3. Click Save to save any changes you made, or click Cancel to return to the WebAccelerators screen.
Exchange SSL certificates

After you configure the central and remote WebAccelerators on one WebAccelerator system, you must exchange SSL certificates between the systems by logging on to all the other WebAccelerator systems in the deployment, and running a script on each machine. You are required to run this script only upon initial configuration, or any time that you add a new WebAccelerator system to the symmetric deployment. After the initial SSL certificate exchange, synchronization between the systems occurs automatically.
To exchange SSL certificates from the command line

1. From the command line of each remote WebAccelerator system in the symmetric deployment, type the following command:
/usr/local/wa/scripts/wam_add.pl
2. Type Y to run the script. 3. Type the self IP address of the WebAccelerator system on which you performed the initial symmetric deployment configuration, and press the Enter key. 4. Type the central WebAccelerator systems root password each time it is requested, and press Enter.
The WebAccelerator system confirms that it successfully retrieved and loaded the SSL certificate files. You can now view the symmetric deployment from the Configuration utility.
3 - 16
Performing maintenance tasks

After you complete the basic configuration required for the WebAccelerator system to process traffic, you can perform the following procedures, as required. Check system processes Manage system log file rotation
Checking the WebAccelerator system processes

The process that you use to initially configure the WebAccelerator system confirms that the basic functionality of the WebAccelerator system software is working. After you complete the WebAccelerator systems initial installation process and configuration, you can perform additional checks to verify that the software is working correctly.
To check the WebAccelerator system processes from the command line

1. Log on to the BIG-IP system as root. 2. Type the following command:
bigstart status | more
Several process should be running. 3. Verify that the following processes are up: comm_srv hds_prune pvac tomcat waicd You can move through each page by pressing the space bar. 4. After you verify that the processes are running, type q to quit.
Note
For additional information about troubleshooting the system processes, see Using performance reports, on page 5-1.
3 - 17
Chapter 3
Changing the log file monitoring interval

The WebAccelerator system manages hit log files that contain large amounts of data. By default, the WebAccelerator system monitors these logs every hour, and rotates the file any time the size is over 10 MB. This log file rotation helps to avoid filling up the disk partition, which could potentially cause a system failure. You can use the following two Linux shell commands to change the interval at which the WebAccelerator system monitors the system logs, from hourly to daily.
rm /etc/cron.hourly/wa_logrotate ln s /usr/local/wa/scripts/wa_logrotate /etc/cron.daily/wa_logrotate/
For more information about these commands, view the rm and ln man pages. For information about changing the log file rotation interval, see Changing log file rotation parameters, on page 4-11.
3 - 18
4
Understanding object classification Understanding URL normalization Customizing options in the pvsystem.conf file
Understanding object classification

Before sending a response to a client, the WebAccelerator system enters an informational X-PvInfo response header into the response to describe how it handled the response. You cannot change these informational headers, and they do not affect processing, however, they can provide useful information for evaluating the efficiency of your acceleration policies. Part of the information included in the X-PvInfo response header is the object type. The WebAccelerator system classifies, by object type and group, every response it receives from the origin web servers. The object type and group classification determine how the WebAccelerator system handles compression for the response.
Classifying by object type

To classify a response by object type, the WebAccelerator system reviews the response headers and classifies the responses based on the first information it finds, in the following order: File extension in the Content-Disposition headers file name field File extension in the Content-Disposition headers extension field Content-Type header in the response, unless it is an ambiguous MIME type Extension of the path in the request For example, if the extension in the Content-Disposition headers file name field is empty, then the WebAccelerator system looks at the Content-Disposition headers extension field. If Content-Disposition headers field has an extension, the WebAccelerator system checks to see if an object type is configured for the extension. If there is no match, it assigns an object type of other, and uses the object settings for other. The WebAccelerator system looks at the information in the Content-Type header only if there is no extension in the Content-Disposition headers file name or extension fields.
Classifying by group
In addition to classifying the response by object type, the WebAccelerator system also classifies the response by group. For example, in the following X-PvInfo response header the object type (OT) is defined as Microsoft Word (msword) and the object group (OG) is documents.
X-PvInfo: [S10101.C30649.A28438.RA0.G0.U58517886].[OT/msword.OG/documents]
Note
For information about the other content contained in a X-PvInfo response header, see the Policy Management Guide for the BIG-IP WebAccelerator System.
4-1
Chapter 4
Managing object types

The WebAccelerator system offers the following object types. Pre-defined Object Types The WebAccelerator system ships with several predefined object types, most of which are optimized for objects associated with specific applications. User-defined Object Types A user-defined object type is an object type that you create and for which you specify all of the parameters dictating how the WebAccelerator system manages the specified object type. The Objects Types screen displays all of the object types that the WebAccelerator system is currently applying to your acceleration policies.
To access the Object Types screen

In the navigation pane, expand WebAccelerator, click Policies, then click Object Types. Figure 4.1 shows an example Object Types screen.
Figure 4.1 Object Types screen

4-2
From the Object Types screen, you can view the object types that the WebAccelerator system is currently applying to acceleration policies, as well as access additional screens where you can perform the following tasks: Create a user-defined object type. View and modify the settings for an existing user-defined or predefined object type. Delete a user-defined object type.
Note
You can delete only user-defined object types; you cannot delete predefined object types. When you create a new object type or modify an existing object type, the WebAccelerator system applies the object type changes globally to all acceleration policies. If you have an optional symmetrical deployment, new objects types that you create and changes that you make to existing objects synchronize with the other WebAccelerator systems in the symmetrical deployment.
Note
For more information about configuring a symmetrical deployment, see Using a symmetric deployment, on page 3-12.
To create a user-defined object type

1. In the navigation pane, expand WebAccelerator, click Policies, and then click Object Types. The Policies, Object Types screen displays a list of user-defined and predefined object types. 2. Click the Create button. The Policies, Object Types, New Object Type screen displays settings for a new object type. 3. In the Description box, type a descriptive name to display on the Object Types screen for the new object. For example, Rich Text Format. 4. In the Object Type box, type a short name for the new object. For example, rtf. This name displays on the Object Types screen and in the X-PvInfo response header. 5. From the Group list, select a group that you want to display in the X-PvInfo response header for the new object. Alternatively, select Add a new group, and type a new group name in the box. 6. For each extension you want to add for the new object, click the Add button and type the extension, as a single value, into the box. For example, rtx.
4-3
Chapter 4
Note: Do not include a preceding period ( . ) when specifying an extension. When the WebAccelerator system finds a file extension in a file name or in the Content-Disposition header of the response, it attempts to match that extension to one of the values that you specified. If there is a match, it classifies the response as the object you specified for the extension. 7. For each MIME type you want to add for the new object, click the Add button and type the MIME type, as a single value, into the box. For example, application/rtf. If the WebAccelerator systems does not find an extension in the name or extension fields of the Content-Disposition header, it looks in the Content-Type header of the response to attempt to match that to one of the MIME types you specified. If there is a match, it classifies the response as the object you specified for the MIME type. 8. From the Enable Compression list, select one of the following to specify when the WebAccelerator system should use gzip in the response: Policy Controlled Uses the compression setting specified in the assembly rule, which the WebAccelerator system matched for this object type. This is the default setting. In Symmetric Deployment only Compresses the response only if the client is another WebAccelerator system in a symmetric deployment. Keep in mind that if you select this option, it supersedes the assembly rules Enable Content Compression setting for this object type. Select this option only if you have a symmetric deployment and want the WebAccelerator system to compress this object type when it is sent between a central and remote WebAccelerator system. None Never compresses the response. Keep in mind that if you select this option, it overrides the assembly rules Enable Content Compression setting for this object type. Select this option only if you want the WebAccelerator system to ignore the compression setting for any configured assembly rules that matches to the specified object type. 9. Click Save. The screen refreshes and the new object type that you created displays in the User-defined Object Types table and the WebAccelerator system applies the new object type to all acceleration policies.
4-4
To view and edit an existing user-defined or predefined object type

1. In the navigation pane, expand WebAccelerator, click Policies, and then click Object Types. The Policies, Object Types screen displays a list of user-defined and predefined object types. 2. Click the name of an object that you want to view. 3. Edit the object type parameters as required. For specific information about each setting, see the online help. 4. Click Save. The WebAccelerator system applies object type changes to all acceleration policies. To return to the Object Types screen without saving the object, click the Cancel button. When you modify a predefined object type and save it, an information icon displays next to the display name in the predefined object types table, indicating that the parameters for the object type are modified from the original version that was shipped with the WebAccelerator system.
To delete a user-defined object type

WARNING
If you delete a user-defined object type, you cannot recover it. 1. In the navigation pane, expand WebAccelerator, click Policies, and then click Object Types. The Policies, Object Types screen displays a list of user-defined and predefined object types. 2. Select the check box next to the user-defined object that you want to delete, and click the Delete button. 3. Click the Delete button again to confirm the deletion, keeping in mind that you cannot recover a deleted object type. The screen refreshes and the object type that you deleted no longer displays in the User-defined Object Types table. To return to the Object Types screen without deleting the object, click the Cancel button.
4-5
Chapter 4
To globally revert object types to default settings from the command line
WARNING
When you use the following commands, the WebAccelerator system resets all object type options to the default settings. All customized settings, including normalization settings and user-defined object types you may have created, are lost. From the command line, type the following commands:
cp -f /usr/local/wa/config/defaults/globalfragment.xml /config/wa bigstart restart comm_srv pvac
Understanding URL normalization

When the WebAccelerator system receives a response, it analyzes the contents of the response and creates an object ID based on the specific content. To recognize content independent of its URL, the WebAccelerator system inserts the object ID it created into the response that it returns to the client. This process is called URL normalization. The normalized objects are stored in a separate application called Normalization. Another component of the URL normalization process is the option to send the normalized URL to the requesters browser. When the URL Normalization to Browser setting is enabled, the WebAccelerator system sends the normalized URL in the form of a redirect to the client browser, so that the browser can search its own cache for a copy of the content based on the requests URL. If the browser finds the content in its own cache, the WebAccelerator system does not have to send the response again, which reduces bandwidth usage and speeds up the response time to the client. By default, the WebAccelerator system: Always performs URL normalization when responding to a client browser. Performs URL normalization only for responses that contain objects that are classified in a documents group. (A documents group consists of objects or files that are 20KB or larger in size, and contain Microsoft Word, Microsoft Excel, and Microsoft PowerPoint objects, or Adobe PDF files.) Has the virtual base path, where the normalized objects appear to come from, set to /pv_obj_cache. Has the authorization and authentication security disabled. It is important that you are aware of the associated restrictions and security considerations when the URL Normalization to Browser setting is enabled.
4-6
If your web site contains frame sets embedded using JavaScript, it is possible that the redirects to a browser will fail. Although this is not typically an issue if you specify documents as the only object group, it can occur. For browser bookmarks, you should bookmark only the original URL. Normalized URL bookmarks are not valid.
WARNING
If you enable URL normalization, you should also set the Required Authorization setting to Yes to prevent the risk that a client might use the normalized URL to access secure content.
Managing URL normalization settings

You can define whether the WebAccelerator system performs URL normalization and whether it uses a redirect to send the normalized content to browsers. You can also specify the type of content on which you want the WebAccelerator system to perform URL normalization.
To view and modify URL normalization settings

WARNING
The WebAccelerator system applies changes globally, to all acceleration policies. 1. In the navigation pane, expand WebAccelerator, click Policies, and then click URL Normalization. The Policies, URL Normalization screen displays settings to normalize content. 2. Modify the settings, as required. For specific information about each setting, see the online help. 3. Click Save, or click Cancel to revert to the previous settings.
Following is an example of the screen, from which you edit the URL normalization settings.
4-7
Chapter 4
Figure 4.2 Edit URL Normalization screen
Selectively disabling content-based identity

If you do not want the WebAccelerator system to normalize certain URLs, you can selectively disable the content-based identity feature associated with a certain document type (node) for a specific user-defined acceleration policy. The WebAccelerator system does not normalize redirects for any requests or responses that match to a node that has content-based identity disabled, and it does not perform content-based cache routines for those nodes.
4-8
You disable content-based identity and normalization for a specific node in a user-defined acceleration policy, using an assembly rules advanced assembly options.
Important
You can disable the content-based identity for specific nodes only if the URL Normalization option is set to Enable. This setting is global; therefore, if the URL Normalization option is set to Disable, the WebAccelerator system does not perform URL normalization on any URLs.
To disable content-based identity for a node

1. In the navigation pane, expand WebAccelerator, and click Policies. The Policies screen displays a list of existing acceleration policies. 2. Click the name of the acceleration policy that you want to modify. 3. Click the node for which you want to disable content-based identity. 4. From the Matching Rules list on the Policy Editor menu bar, select Acceleration Rules. 5. On the Policy Editor menu bar, click Assembly. 6. From the Content Assembly Options list, select Advanced. The screen refreshes to display additional options. 7. In the Advanced Assembly box, type:
disableContentBasedIdentity=true
8. Click Save.
For a new or modified acceleration policy to be in effect for your site, you must publish it. One way to do this is to click the Publish button from any screen within the Policy Editor to open the Publish screen.
4-9
Chapter 4
Customizing options in the pvsystem.conf file

After you install and configure the WebAccelerator system, you can customize the system for your site by changing the default settings for the following options: Log file rotation Compiled response TTL parameters Cookie encryption HDS prune To modify these settings, you edit the /config/wa/pvsystem.conf file.
Important
Before you make changes to the /config/wa/pvsystem.conf file, we recommend that you first create a backup copy using the cp /config/wa/pvsystem.conf/config/wa/pvsystem.conf.back command. This enables you to easily restore the modified configuration in case of a system failure.
To edit the pvsystem.conf file

1. Log on to the BIG-IP system as root. 2. Edit the /config/wa/pvsystem.conf file as required. The parameters for these options are specified on the following pages. 3. Save the file. 4. Restart the process that you modified, using the command specified in the following sections.
4 - 10
Changing log file rotation parameters

The WebAccelerator system generates information about page requests in log files called change logs, and information similar to web server log files in hit logs. By default, the WebAccelerator system buffers the change log and hit log information in memory until it reaches a size of 10 MB, at which time it writes the information to the hard drive (rotates). The threshold for the data in the hit and change logs is based on content size and Time-to-Live (TTL) value. The WebAccelerator system resets the TTL values each time it writes the change log or hit log to disk. For example, by default, if the WebAccelerator system writes a change log at 3 minutes because a file size reached the limit, it resets the TTL counter to 0 and does not write the change log again until either 5 minutes have elapsed, or it has collected 1MB of data, whichever comes first.
WARNING
The default values for the size and TTL threshold limits work well for most configurations, and you should not change them unless instructed to do so by an F5 Network Technical Support Engineer. If you are instructed to change the size or TTL threshold values for hit or change logs, you can modify the /config/wa/pvsystem.conf file parameters described in Table 4.1. After you change a parameter, save the file and then restart the process using the bigstart restart pvac command.
Parameter changeLogFileSize Description Maximum amount of change log data allowed buffered in memory before the WebAccelerator system writes change log data to disk. Default is 1000000 (1MB). Maximum amount of hit log data allowed buffered in memory before the WebAccelerator system writes change log data to disk. Default is 1000000 (1MB). Interval at which the WebAccelerator system writes change log data to disk, regardless of how much change log data is buffered in memory. Default is 5 minutes. Interval at which the WebAccelerator system writes hit log data to disk, regardless of how much hit log data is buffered in memory. Default is 5 minutes.
hitLogFileSize
changeLogFileTTL
hitLogFileTTL
Table 4.1 Log file parameters
4 - 11
Chapter 4
Changing TTL parameters for compiled responses

The WebAccelerator system assigns a Time-to-Live (TTL) value to every compiled response that it caches. The TTL value defines the time that is allowed to elapse before the compiled response expires and the WebAccelerator system sends a request to the origin web server for fresh content. This length of time is called the content lifetime, and can vary for each compiled response. For most compiled responses, you can define the content lifetime using acceleration policies. (See the Policy Management Guide for the BIG-IP WebAccelerator System for more information.) Another option is to adjust the TTL values using the various lifetime mechanisms available in the HTTP and ESI protocols. However, in either case you cannot set TTL values to exceed the system limits that are controlled with the parameters that are defined in the /config/wa/pvsystem.conf file. If you determine that you need to change the system limit TTL values for compiled responses, you can modify the /config/wa/pvsystem.conf file parameters described in Table 4.2. After you change a parameter, save the file and then restart the process using the bigstart restart pvac command.
Parameter staticMinTTL Description The system-wide minimum TTL value for static content, like images. Default is 0 seconds. The system-wide maximum TTL value. Default is 86400 seconds (24 hours). A system-wide default value for the HTTP last mod factor. The WebAccelerator system uses this value in an equation that determines TTL values based on information found in HTTP headers. You can use acceleration policies to override this default value.
staticMaxTTL
staticLastModFactor
Table 4.2 TTL parameters
Note
Content lifetime and TTL values are described in further detail in the Policy Management Guide for the BIG-IP WebAccelerator System.
4 - 12
Changing cookie encryption parameters

The WebAccelerator system is capable of encrypting cookies that it sets on a client. When the client presents the cookie back to the WebAccelerator system, the WebAccelerator system decrypts it and processes it. Further, if the WebAccelerator system must send a request to the origin web servers, it decrypts the cookie before it sends a response to the client. By using encrypted cookies, you ensure that the client cannot examine the information contained in the cookie. This can prevent malicious users from examining the contents of your cookies and gaining knowledge about how your site works. If you determine that you need to change the default settings for cookie encryption, you can modify the /config/wa/pvsystem.conf file parameters described in Table 4.3. After you change a parameter, save the file and then restart the process using the bigstart restart pvac command.
Parameter encryptCookieNames Description When this parameter is set to true, the WebAccelerator system encrypts cookie names. When this parameter is set to true, the WebAccelerator system encrypts cookie values. When this parameter is set to true, the WebAccelerator system examines the IP address of the client presenting the cookie before decrypting the cookie. Using this feature can reduce performance slightly, however, it ensures that the WebAccelerator system decrypts a cookie only if it is presented by the client to which the cookie was originally set. encryptCookieMatching When this parameter is used, the WebAccelerator system only encrypts cookies with a name that matches the provided regular expression. You must include the start of line (^) and end of line ($) expressions. For example, to encrypt all cookies that begin with myDomain, use: ^myDomain.*$
encryptCookieValues
encryptCookieVerifyIP
Table 4.3 Cookie encryption parameters
4 - 13
Chapter 4
Changing default values for HDS prune

The WebAccelerator system uses a shell script called hds_prune to clear any compiled responses that are no longer needed from the WebAccelerator systems on-disk cache. The script works by periodically checking the current capacity of the on-disk cache. If the amount of available free space for the on-disk cache is less than or equal to the minimum amount specified by the hdsPruneStartLevel parameter, the script prunes the cache. When pruning, the script removes enough data from the on-disk cache to satisfy the maximum amount specified by the hdsPruneStopLevel parameter. That is, when the script is done, the amount of free space in the on-disk cache partition is as big as the maximum specified by the hdsPruneStopLevel parameter. If you determine that you need to change the default settings for the hds_prune script, you can modify the /config/wa/pvsystem.conf file parameters described in Table 4.4. After you change a parameter, save the file and then restart the process using the bigstart restart pvac command.
Parameter
hdsDiskScanInterval
Definition
The length of time that passes before the script starts checking the current amount of free space available in the on-disk cache partition. Default is 300 seconds (5 minutes). The smallest amount of free space allowed in the on-disk cache partition. If hds_prune finds that the on-disk cache partition has a free space value that is less than or equal to this value, then it prunes the on-disk cache. Values are expressed as a percentage of free space. The default is to start pruning when there is less than 20% of the disk free. The amount of free space that must be available in the partition when hds_prune is finished pruning the on-disk cache. Values are expressed as a percentage of free space. The default is to stop pruning when there is at least 40% of the disk free. The location of the on-disk cache. Default is /wam/hds.
hdsPruneStartLevel
hdsPruneStopLevel
hdsLocation
Table 4.4 HDS prune script parameters
4 - 14
5
Using performance reports Using error and status log files Using system log files Resolving communication system failures Using X-PvInfo response headers Invalidating and clearing the WebAccelerator systems cache
Using performance reports

The WebAccelerator systems performance reports provide you access to information about page requests, the frequency of those requests, and how well the WebAccelerator system serviced those requests from its cache. You can use these performance reports to evaluate your acceleration policies, adjusting them as required to maximize client access to your applications. You access the performance reports screens by expanding WebAccelerator, located on the Main tab of the navigation pane. Once you expand WebAccelerator, additional options display as shown in Figure 5.1.
Figure 5.1 WebAccelerator options on the navication pane
The three types of performance reports are:
Traffic Reports Displays the number of requests (hits) received, and responses served, by the WebAccelerator system. Byte Reports Displays the bytes of content that the WebAccelerator system has sent in response to requests. Response Reports Displays the average amount of time it takes the WebAccelerator system to respond to a request from the client.
5-1
Chapter 5
You can easily customize individual performance reports to display information based on different criteria. The WebAccelerator system also provides you with an option to save performance reports to a specified file type so that you can import them into specific applications.
To edit the performance reports filter

1. In the navigation pane, expand WebAccelerator, and click Traffic Reports, Byte Reports, or Response Reports. The reports screen displays data for the respective report. 2. Click the Edit Filter button. 3. Change the following options as required. Time Period Content Properties Transaction Type For more information about these options, click the Help tab on the the navigation pane. 4. Click Update to save your changes.
The individual performance reports display content according to the parameters that you select for the filter. Any changes that you make to the filter values stay in effect for all reports, until you change them.
To export a performance report file to a specific file type

1. From any performance report screen, select one of the following export options, located at the bottom of the screen: CSV Excel XML The system prompts you to save the file. 2. Click Save. 3. Browse to a location on your computer or network to save the file. 4. Change the file name as required, and click Save.
5-2
Using error and status log files

The WebAccelerator system stores information and error messages and status for the following services: tomcat intelligence interface (waui) pvac When troubleshooting issues with the WebAccelerator system, you can look in the log files for these services, to see if error conditions exist. Use these log files for troubleshooting purposes only. By default, the WebAccelerator system rotates the service files on an hourly basis. For information about how to configure log file rotation, see Changing the log file monitoring interval, on page 3-18.
tomcat
The tomcat service hosts the Configuration utility user interface, from which you configure the WebAccelerator system. The tomcat log files are located in: /var/log/tomcat/catalina.out
intelligence interface
The intelligence interface (waui) service publishes acceleration policies (and changes to acceleration policies) to the WebAccelerator system. The intelligence interface log files are located in: /var/log/tomcat/localhost_waui_log.txt
pvac
The pvac service manages HTTP and HTTPS traffic in accordance to the associated acceleration policy. The pvac log files are located in: /var/log/wa/pvac.log
5-3
Chapter 5
Using system log files

The WebAccelerator system provides the following configuration, log, and performance report data files: /config/wa/* /var/log/wa/* /var/lib/mysql/WA/PERFMONITOR_DATA.MYD /var/lib/mysql/WA/PERFMONITOR_DATA.MYI /var/lib/mysql/WA/PERFMONITOR_DATA.frm For troubleshooting purposes, you can compile system log information into a single file, by typing the following command:
tar czvpf /var/tmp/wa.config-data.tgz /config/wa/var/lib/mysql/WA/PERFMONITOR_DATA.* /var/log/wa
Note
For information about managing log file rotation, see Changing the log file monitoring interval, on page 3-18.
5-4
Resolving communication system failures

Most communications system failures are caused by one of the following issues.
Port definitions A process was unable to obtain the port defined for it in the pvsystem.conf file. This most likely means that a process that was using that port did not shut down properly. You can use the netstat(8) command to see what process is currently using the port. Upstream processes A process was unable to connect to its upstream (parent) process. Some possible reasons for not being able to connect to an upstream process are: Upstream process is not running Check the system processes (see Checking the WebAccelerator system processes, on page 3-17) and restart them as required. Network misconfiguration Verify that the host names identified in the pvsystem.conf file are configured in DNS, and that they resolve to the correct IP addresses, and then ping the systems over the network. Firewall misconfiguration Verify that the firewall is open for both incoming and outgoing TCP/IP traffic for all relevant hosts and ports.
SSL certificates The communications system uses certificate-based encrypted traffic (SSL version 3). If the certificates are corrupt or expired, or not yet valid in certain pathological cases, then communications cannot be established. If you suspect there is an issue with the SSL certificate, check the validity of the certificate on the upstream and downstream systems, using the openssl command: openssl verify/usr/local/wa/config/ssl/pvssl.pem If there is an issue, the last line of output does not display OK. Note that Error 18 (self-signed certificate) is reported for all default WebAccelerator system installations. This is considered an acceptable error if the openssl command reports OK.
Time is not synchronized The WebAccelerator system uses NTP to keep all system clocks synchronized. The communications system is sensitive to time synchronization issues and the clocks must be within 1000 seconds of each other for NTP to be able to correct the differential. This limit can be exceeded if there is a hardware clock failure on a host. Check the time hosts in your installation. If they are not synchronized, verify that NTP is running on each host and check for NTP errors in the /var/log/wa/messages file. For information, see Defining an NTP server, on page 3-2.
5-5
Chapter 5
Using X-PvInfo response headers

When sending a response to a client, the WebAccelerator system inserts an informational X-PvInfo response header, as described in Understanding object classification, on page 4-1. This X-PvInfo response header includes codes that you can use to assess the effectiveness of your acceleration policy rules. You can view X-PvInfo response headers by: Performing a packet capture of the page. Using an HTTP viewer utility like HttpWatch, HTTP Analyzer, or Live Headers. Using the WebAccelerator systems hit logs. For additional information, including definitions of each X-PvInfo response header code, see the Using HTTP Headers chapter of the Policy Management Guide for the BIG-IP WebAccelerator System.
5-6
Invalidating and clearing the WebAccelerator systems cache

Depending on the type of object, the WebAccelerator system stores content in one of the following caches: Hot Cache Used to store objects that do not require special assembly. Smart Cache Used to store objects that require special assembly processing, such as objects for which variation rules apply. Typically, you use invalidation rules to expire specific content stored in the Smart Cache. When you invalidate content, that content is immediately expired but not removed from the disk. There may be occasions, however, such as when troubleshooting cache issues, when you want to clear cache and remove all of the content from the disk that the WebAccelerator system has stored in both the Smart Cache and the Hot Cache.
Important
Invalidating or clearing the cache on the WebAccelerator system temporarily increases traffic to the origin web servers until the WebAccelerator system repopulates the cache.
To invalidate cached content for specific applications or type of content

1. On the Main tab of the navigation pane, expand WebAccelerator, and click Invalidate Content. The Invalidate Content screen displays a list of applications. 2. Select the check box next to the application for which you want to invalidate the cache. 3. Alternatively, you can invalidate cache for specific types of content stored in associated applications: Select the check box next to Normalized to invalidate all content on which the WebAccelerator has performed URL normalization. For more information about normalized content, see Understanding URL normalization, on page 4-6. Select the check box next to Unmapped to invalidate all content for unmapped hosts. Note that this application is available only if you have enabled unmapped host processing. For more information, see Processing unmapped requests, on page 3-9. 4. Click the Invalidate button.
5-7
Chapter 5
To clear all cached content from the command line

1. Log on to the BIG-IP system as root. 2. Type the following command:
wa_clear_cache
This command restarts the pvac service, which may temporarily halt the flow of HTTP traffic, and the WebAccelerator system displays the following messages:
Stopping WebAccelerator .................... okay Clearing disk cache directory .............. okay Starting WebAccelerator .................... okay
Note
For information about configuring invalidation rules, see the Policy Management Guide for the BIG-IP WebAccelerator System.
5-8
Glossary
Glossary
acceleration policy An acceleration policy is a collection of rules that determine how the WebAccelerator system caches, assembles, and responds to HTTP requests. There are three types of acceleration policies offered with the WebAccelerator system: predefined acceleration policies, user-defined acceleration policies, and signed acceleration policies. See the Policy Management Guide for the BIG-IP WebAccelerator System for more information about acceleration policies. See also acceleration rules, matching rules, predefined acceleration policy, user-defined acceleration policy, and signed acceleration policy. acceleration rules Acceleration rules dictate how the WebAccelerator system manages HTTP requests. Some acceleration rules pertain to how the WebAccelerator system handles a request, and some pertain to how the WebAccelerator system handles the response. Each acceleration rule is associated with a matching rule, represented by a leaf node on the Policy Tree. See also matching rules and Policy Tree. application matching Application matching is the process of mapping HTTP requests and responses to associated application profiles. To perform application matching, the WebAccelerator system analyzes information in an HTTP request to match the request to an application profile that you created, and then apply the associated acceleration policys matching rules to group the request and response to a specific leaf node on the Policy Tree. Once matched to a leaf node, the WebAccelerator system applies the acceleration policys acceleration rules to each group. See also acceleration rules, application profile, and matching rules. application profile An application profile provides the key information that the WebAccelerator system needs to appropriately handle requests to the applications on your site. An application profile consists of a host map and an associated acceleration policy. See also application matching, host map, and acceleration policy. assembly Assembly is the process by which the WebAccelerator system puts together information that it has received from the origin web servers and saved in an internal (compiled response) format, to respond to an HTTP request. asymmetric deployment When configured in an asymmetric deployment, one or more WebAccelerator systems are located on one end of a wide area network.
Glossary - 1
Glossary
central WebAccelerator system In a symmetric deployment, the central WebAccelerator system is the WebAccelerator system that is closest to the application it is accelerating. The application can be accessed through the central WebAccelerator system by local clients, as well as by clients through a remote WebAccelerator system located in a separate geographic location. See also symmetric deployment and remote WebAccelerator system. change logs Change logs contain information about page requests. The WebAccelerator system buffers change log information in memory until the specified threshold is reached. Once the threshold is reached, the WebAccelerator system writes the information to the hard drive. compiled response A compiled response consists of the information that the WebAccelerator system received from the origin web server, saved in an internal format. The WebAccelerator system uses the compiled response object that it created, to assemble responses. See also assembly. Configuration utility The Configuration utility is the browser-based graphical user interface for the BIG-IP and WebAccelerator system. The Configuration utility provides you access to the WebAccelerator module, as well as the network, system, and local traffic configuration objects. content lifetime Content lifetime is the length of time that is allowed to elapse before the compiled responses expire, and the WebAccelerator system sends a request to the origin web server for fresh content. Content lifetime can vary for each compiled response. data center A data center is a logical collection of both servers and links. Typically, data centers represent a collection of WebAccelerator systems that reside in a physical location. documents group A documents group consists of objects or files that contain Microsoft Word, Microsoft Excel, and Microsoft PowerPoint objects, or Adobe PDF files.
Glossary - 2
Glossary
Edge Side Includes Edge Side Includes (ESI) is a simple markup language that supports web surrogates, such as the WebAccelerator system, and is used to define web page components for dynamic assembly and delivery of web applications. For more information about Edge Side Includes (ESI) see the Policy Management Guide for the BIG-IP WebAccelerator System. enterprise MIB files Enterprise MIB files are MIB files that pertain to a particular company, such as F5 Networks, Inc. See also MIB files. global address A global address is an IP address that the WebAccelerator system uses to communicate with computers outside of a data center. See also internal address and data center. hds_prune hds_prune is a shell script that clears compiled responses that are no longer needed from the WebAccelerator systems on-disk cache. This script periodically checks the current capacity of the on-disk cache, and when required, removes enough data to satisfy the specified maximum amount. That is, when the script is done, the amount of free space in the on-disk cache partition is as big as the maximum you set. hit logs Hit logs contain the same type of information as the web server log files. The WebAccelerator system buffers hit log information in memory until the specified threshold is reached. Once the threshold is reached, the WebAccelerator system writes the information to the hard drive. host map A host map is defined for each application profile, and contains a list of hosts to which the WebAccelerator system can match HTTP requests. See also application profile. Hot Cache The WebAccelerator system uses Hot Cache to serve content that does not require special assembly. internal address An internal address is an IP address that the WebAccelerator system uses to communicate with other WebAccelerator systems within a data center. See also global address and data center.
Glossary - 3
Glossary
matching rules Matching rules are based on specific parameters for HTTP request data types and HTTP response data types. The WebAccelerator system uses matching rules to look for identified objects in an HTTP request or response, such as path, file extension, cookie, or query parameter, in order to group the requests and responses. See also Policy Tree and acceleration rules. MultiConnect The WebAccelerator systems MultiConnect feature modifies embedded URLs with unique subdomains, prompting the clients web browser to additional TCP connections to the WebAccelerator system for each subdomain when requesting pages over the HTTP protocol. These additional browser connections result in faster data downloads. Network Time Protocol Network Time Protocol (NTP) is a protocol that synchronizes the clocks on the network. object ID Each object defined in the MIB has a unique object ID (OID), written as a series of integers. The OID indicates the location of the object within the MIB tree structure. object types An object type consists of configured parameters specifying how the WebAccelerator system should manage objects that it receives in responses from the origin web server. The WebAccelerator system enters the object type and group into the informational X-PvInfo response header. origin web servers Web servers, application servers, and database servers are collectively referred to as origin web servers. Origin web servers can serve all possible permutations of the content offered by your site, while the WebAccelerator system only stores and serves page content combinations that were previously requested by clients visiting your site. Performance Reports Performance Reports include information about page requests, the frequency of those requests, and how well the WebAccelerator system serviced those requests from its cache. Policy Editor From the Policy Editor screen, you can view a predefined acceleration policy, or create or modify a user-defined acceleration policy.
Glossary - 4
Glossary
Policy screen From the Policies screen, you can access additional screens, from which you can perform additional tasks. Policy Tree The Policy Tree is located on the left side of the Policy Editor screen, and is composed of nodes. The WebAccelerator system performs application matching against leaf nodes that correspond to specific matching rules, and then applies the associated acceleration rules. pops When the WebAccelerator system meets the maximum limit for in-memory cache, it removes (or pops) cached objects that have not been accessed for the longest period of time. predefined acceleration policy The WebAccelerator system comes with several predefined acceleration policies, most of which are optimized for a specific application. Additionally, the WebAccelerator system offers predefined acceleration policies for general delivery, which are not application specific. You can use the Policy Editor to view, add, or modify the rules for predefined acceleration policies. See also Policy Editor, user-defined acceleration policy, and signed acceleration policy. remote WebAccelerator system In a symmetric deployment, the remote WebAccelerator system accesses applications from a central WebAccelerator system located in a separate geographical location from itself, but in the same location as the application and origin web server. See also central WebAccelerator system and symmetric deployment. requested host When you create a host map, you identify the domain as it appears on the HTTP Host request header. These domains are called requested hosts. See also host map. response rewrite scripts Response rewrite scripts manipulate HTTP responses that the WebAccelerator system receives from the origin web servers. This manipulation occurs before the response is processed by the WebAccelerator system, so it is the manipulated response that the WebAccelerator system manages and caches, not the actual response sent by the origin web servers. For information about customizing response rewrite scripts, contact F5 Networks Technical Support.
Glossary - 5
Glossary
Rewrite Engine The Rewrite Engine is a procedural language for writing custom response rewrite scripts to manipulate HTTP responses received from the origin web servers. For information about customizing response rewrite scripts, contact F5 Networks Technical Support. See also response rewrite scripts. signed acceleration policy A signed acceleration policy is created, certified, encrypted, and provided to you by its author, such as a consultant or vendor, to import into your WebAccelerator system. Unlike predefined or user-defined acceleration policies, you cannot view, add, or modify the rules for a signed acceleration policy. See also acceleration policy. Smart Cache Smart Cache is the repository from which the WebAccelerator system serves objects that require specific assembly processing, such as objects for which variation rules apply. swap space Swap space is an area on the disk that is used as virtual memory to temporarily hold the least-used files from real memory (RAM). Sufficient swap space is important to ensure that some RAM is free at all times. symmetric deployment A symmetric deployment is an optional deployment that consists of central and remote WebAccelerator systems that have synchronized configurations. A symmetric deployment allows users to transparently utilize the functionality of a WebAccelerator system with another network across town, or across the globe, from both sides of the transaction. See also central WebAccelerator system and remote WebAccelerator system. transforms Transforms are the process that the WebAccelerator system uses to manipulate HTTP data. Unique Content Identifier (UCI) The origin web server generates specific responses based on certain elements in the request, such as the URI and query parameters. The WebAccelerator system includes these elements in a UCI that it creates, so that it can easily match future requests to the correct content in its cache. The WebAccelerator system matches content to the UCI for both the request and the compiled response that it created to service the request.
Glossary - 6
Glossary
unmapped request An unmapped request is a request for a domain that is not listed in the requested host map. By default, the WebAccelerator system replies to clients that request unmapped hosts with an HTTP 403 response code. F5 Networks recommends that you reconcile unmapped requests by adding the host name to the host map for the applications that are using the specified application policy set. See also host map. URL normalization URL normalization is the process by which the WebAccelerator system creates and inserts an object ID based on specific content into a response, before it returns the response to the client. user-defined acceleration policy A user-defined acceleration policy is a policy that you create by either copying an existing policy and modifying the rules, or by creating a new acceleration policy and specifying all new rules. You can use the Policy Editor to view, add, and modify the rules for user-defined acceleration policies. See also Policy Editor, predefined acceleration policy, and signed acceleration policy. X-PvInfo response headers An X-PvInfo response header is an information header that contains data about how the WebAccelerator system handled a particular HTTP request. Before sending a response to a client, the WebAccelerator system enters the X-PvInfo response header into the response.
Glossary - 7
Glossary
Glossary - 8
Index
Index
A
About tab, about 1-5 acceleration policies accessing 1-7 and Level 1 Delivery 3-6 and Level 2 Delivery 3-6 and the intelligence interface 5-3 managing 1-7 acceleration rules defined 2-2 application matching defined 2-2 application profiles and host maps 3-5 configuring 3-7 defined 3-5 application servers. See origin web servers. assembly rule parameters using to recreate page 2-4 asymmetric deployment defined 1-2
B
bookmarks and normalized URLs 4-7 and redirecting browsers 4-7 browser behavior controlling 1-1 browser support for the Configuration utility 1-4 browsers and bookmarks 4-7 and redirects 4-6 and support for the Configuration utility 1-4 redirecting 4-6 Byte Reports 5-1
C
cache and Hot Cache 5-7 and Smart Cache 5-7 clearing all content 5-7 managing on-disk 2-2 servicing requests from 2-1 cache invalidation performing 5-7 cached content clearing 5-7 central WebAccelerator systems configuring for a symmetric deployment 3-14 defined 1-3, 3-12 certificates and SSL 5-5 exchanging SSL certificates 3-16
change logs and Performance Reports 2-5 and TTL value 4-11 defined 2-5 managing 4-11 modifying file size 4-11 modifying TTL 4-11 clearing cache 5-7 client requests responding 2-2 communication system and firewall 5-5 troubleshooting 5-5 communications managing between peers 2-2 managing between processes 2-2 communications server 2-2 compiled responses and content lifetime 4-12 and TTL parameters 4-12 assigning UCI 2-2 modifying TTL parameters 4-10 compression applying 4-1 configuration performing optional tasks 3-9 configuration examples and asymmetric deployment 1-2 Configuration utility and browser support 1-4 and components of 1-5 and licensing 1-4 and the Welcome screen 1-4, 1-9 and tomcat 5-3 defined 1-4 using 1-4 content accelerating access 1-1 processing 2-2 content lifetime and TTL values 4-12 defined 4-12 content management 2-2 content-based identification disabling 4-9 Content-Disposition header using to classify responses 4-1 Content-Type header using to classify responses 4-1 cookie encryption options and the pvsystem.conf file 4-10 modifying 4-10 cookie parameters for encryption 4-13 cookies and encryption process 4-13
Index - 1
Index
encrypting 4-13 See also cookie encryption options. CSV files saving Performance Reports 5-2
H
HDS prune and script 4-14 and WebAccelerator system processes 2-2 managing 4-14 modifying options 4-10, 4-14 hdsDiskScanInterval parameter 4-14 hdsLocation parameter 4-14 hdsPruneStartLevel parameter 4-14 hdsPruneStopLevel parameter 4-14 headers and X-PvInfo response headers 4-1 Help tab, about 1-5 hit logs and TTL value 4-11 described 2-5 managing 4-11 modifying file size 4-11 modifying TTL 4-11 hits and traffic reports 5-1 host map and requested hosts 3-5 Hot Cache clearing 5-7 defined 5-7 HTTP 403 response codes and unmapped requests 3-9 HTTP responses manipulating 1-1 using Rewrite Engine 1-1 HTTP traffic managing with pvac 2-2 proxying to origin web servers 2-1 servicing with the WebAccelerator system 2-1
D
data center defining a symmetric deployment 3-15 defining for symmetric deployment 3-15 database servers. See origin web servers. documentation finding 1-9 for the WebAccelerator system 1-8 documents group and URL normalization 4-6 defined 4-6
E
encryptCookieMatching parameter 4-13 encryptCookieNames parameter 4-13 encryptCookieValues parameter 4-13 encryptCookieVerifyIP parameter 4-13 encryption for cookies 4-13 error files 5-3 error messages for system processes 5-3 example configurations and symmetric deployment 3-12 Excel files saving Performance Reports 5-2 exporting Performance Reports 5-2
F
F5 Networks Technical Support, accessing 1-9 files and error reporting 5-3 and intelligence interface log files 5-3 and pvac log files 5-3 and status 5-3 and tomcat log files 5-3 firewalls and ports 5-5 and the communication system 5-5 forms and the MultiConnect feature 3-10 frame sets, and redirect issues 4-6
I
image tags and the MultiConnect feature 3-10 intelligence interface service and log file 5-3 defined 5-3 invalidate content clearing cache 5-7 invalidating content clearing all cache 5-8 for specific applications 5-7 for specific types of content 5-7
G
guides finding documentation 1-9
J
J2EE and standard delivery acceleration policies 3-6 Java 2 Platform Enterprise Edition See J2EE.
Index - 2
Index
JavaScript, and redirect issues 4-6
L
Level 1 Delivery acceleration policy 3-6 Level 2 Delivery acceleration policy 3-6 log file monitoring 3-18 log file creation and the pvsystem.conf file 4-10 modifying options 4-10 log file rotation 4-11 log files and change logs 4-11 and hit logs 4-11 and intelligence interface service 5-3 and pvac service 5-3 and tomcat service 5-3 and TTL value 4-11 changing rotation parameters 4-11 creating 4-11 for error and status 5-3 for intelligence interface 5-3 for pvac 5-3 for services 5-3 for tomcat 5-3 managing 2-5 modifying monitoring interval 3-18 rotating 3-18
Network Time Protocol server. See NTP. normalization settings resetting to defaults 4-6 normalized content clearing cache for 5-7 normalized URLs and bookmarks 4-7 and content-based identity 4-6 and redirecting browsers 4-7 disabling 4-9 NTP and the communication system 5-5 configuring server 3-2 NTP server for symmetric deployment 3-13
O
object ID and URL normalization 4-6 defined 4-6 object types accessing 4-2 classifying 4-1 defined 4-1 example 4-1 resetting to defaults 4-6 objects classifying for compression 4-1 on-disk cache pruning 4-14 online help accessing 1-4 optional configuration tasks 3-9 origin web servers classifying response types 4-1 defined 2-1 proxying requests to 2-1
M
Main tab, about 1-5 maintenance tasks checking system processes 3-17 manually invalidating content 5-7 manuals finding documentation 1-9 for the WebAccelerator system 1-8 matching rules defined 2-2 monitoring log files modifying interval 3-18 monitoring processes 5-3 monitoring services 5-3 MultiConnect and default 3-10 and SSL certificates 3-11 and subdomains 3-10 and supported tags 3-10 configuring 3-11 defined 3-10
P
path extensions using to classify responses 4-1 Performance Reports and change logs 2-5 and responses 5-1 and traffic 5-1 and types 5-1 customizing 5-2 defined 5-1 saving to a specific file type 5-2 using 5-1 Policies screen accessing 1-7 Policy screen accessing acceleration policies 1-7 pools Index - 3
N
netstat utility and the communications system 5-5
Index
configuring 3-3 port 22 and symmetric deployment 3-14 port 4353 and a symmetric deployment 3-14 ports and firewall 5-5 predefined acceleration policies and Level 1 Delivery 3-6 and Level 2 delivery 3-6 selecting 3-6 proc_log 5-3 processes checking status 3-17 monitoring log files 5-3 pvac service and log file 5-3 and system processes 2-2 defined 5-3 pvsystem.conf file modifying 4-10 modifying cookie encryption values 4-10 modifying HDS prune options 4-10 modifying options 4-10
R
redirect requests and HTTP traffic 2-1 redirects and browsers 4-6 to origin web servers 2-1 remote WebAccelerator system defining data center 3-15 for a symmetric deployment 3-15 remote WebAccelerator systems defined 1-3, 3-12 Requested Hosts and domains 3-5 defined 3-5 Response Reports 5-1 responses classifying 4-1 Rewrite Engine manipulating HTTP responses 1-1 rewrite scripts using 1-1
S
script tags and the MultiConnect feature 3-10 security and redirects implications 4-6 encrypting cookies 4-13 services and intelligence interface 5-3 Index - 4
and pvac 5-3 and tomcat 5-3 checking status 3-17 monitoring log files 5-3 Smart Cache clearing 5-7 defined 5-7 SSL ceritficates exchanging 3-16 SSL certificates and MultiConnect 3-11 and the communication system 5-5 and troubleshooting 5-5 verifying 5-5 standard predefined acceleration policies 3-6 staticLastModFactor parameter defined 4-12 staticMaxTTL parameter defined 4-12 staticMinTTL parameter defined 4-12 status files 5-3 subdomains and MultiConnect 3-10 Subject Alternative Name entries and MultiConnect 3-11 symmetric deployment configuring 3-14 symmetric deployments and central WebAccelerator system 1-3, 3-12 and example configuration 3-12 and port 22 3-14 and port 4353 3-14 and remote WebAccelerator systems 1-3, 3-12 and waicd process 2-2 configuring 3-13 creating a central WebAccelerator system 3-14 creating a remote WebAccelerator system 3-15 defined 1-2 defining an NTP server 3-13 defining data center 3-15 synchronizing 3-16 viewing and modifying configuration 3-16 system messages viewing 1-5 system processes and communications server 2-2 and HDS prune 2-2 and pvac service 2-2 and waicd 2-2 checking 3-17 system-wide age parameters customizing 4-10
Index
T
Technical Support web site 1-9 Time-to-Live. See TTL. tomcat service and log file 5-3 defined 5-3 Traffic Reports 5-1 troubleshooting and SSL certificates 5-5 and the communications system 5-5 using log files 5-3 TTL and change logs 4-11 and compiled responses 4-12 and content lifetime 4-12 and hit logs 4-11 managing parameters 4-12 TTL parameters modifying for compiled responses 4-10 tunnels and HTTP traffic 2-1
web application and hosted content 3-3 web servers. See origin web servers. Welcome screen for the Configuration utility 1-4, 1-9 wide area network. See WAN.
X
XML files saving Performance Reports 5-2 X-PvInfo response headers defined 4-1
U
UCI assigning to compiled responses 2-2 defined 2-2 Unique Content Identifier. See UCI. unmapped requests and HTTP 403 response code 3-9 defined 3-9 enabling processing for 3-9 URL normalization and default settings 4-6 clearing cache for 5-7 defined 4-6 disabling content-based identity for a node 4-9 modifying parameters 4-7 URLs and normalized 4-6
V
virtual base path, defined 4-6 virtual servers configuring 3-3
W
waicd and symmetric deployment 2-2 and system processes 2-2 WAN and asymmetric configuration 1-2 and symmetric deployment 1-2 waui See intelligence interface service. Configuration Guide for the BIG-IP WebAcceleratorTM System Index - 5
Index
Index - 6

Configuration Guide For The BIG-IP Web Accelerator System

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Configuration Guide For The BIG-IP Web Accelerator System

Uploaded by

Copyright:

Available Formats

Configuration Guide for the BIG-IP WebAccelerator System

Export Regulation Notice

Configuration Guide for the BIG-IP WebAcceleratorTM System

Canadian Regulatory Compliance

Configuration Guide for the BIG-IP WebAcceleratorTM System

About the WebAccelerator system

Managing your applications

Monitoring traffic to your applications

Configuration Guide for the BIG-IP WebAcceleratorTM System

Deployment options for the WebAccelerator system

Figure 1.1 Asymmetric deployment example

Figure 1.2 Symmetric deployment example

Configuration Guide for the BIG-IP WebAcceleratorTM System

Using the Configuration utility

To access the Configuration utility

Figure 1.3 Welcome screen for the Configuration utility

The Configuration utility contains the following components:

Configuration Guide for the BIG-IP WebAcceleratorTM System

Accessing acceleration policies

To access the Policies screen

Figure 1.4 Example Policies screen

Configuration Guide for the BIG-IP WebAcceleratorTM System

Reviewing the documentation set

Finding help and technical support resources

Configuration Guide for the BIG-IP WebAcceleratorTM System

Servicing requests to your origin web servers Generating log files

Overview of the WebAccelerator System

Servicing requests to your origin web servers

Configuration Guide for the BIG-IP WebAcceleratorTM System

Processing HTTP requests and managing responses

Overview of the WebAccelerator System

Figure 2.1 Request/Response flow

Configuration Guide for the BIG-IP WebAcceleratorTM System

Overview of the WebAccelerator System

Generating log files

Configuration Guide for the BIG-IP WebAcceleratorTM System

Initial Configuration and Maintenance Tasks

Completing initial configuration for the Local Traffic Manager

Configuration Guide for the BIG-IP WebAcceleratorTM System

Completing initial configuration for the WebAccelerator system

Defining an NTP server

To define an NTP server

Creating the HTTP class profile

To create the HTTP class profile

Initial Configuration and Maintenance Tasks

Configuring a virtual server and pool

To configure a virtual server and pool

Configuration Guide for the BIG-IP WebAcceleratorTM System

Initial Configuration and Maintenance Tasks

Creating an application profile

Defining your host map

Choosing an acceleration policy

Initial Configuration and Maintenance Tasks

To create an application profile

Verifying the application profile

To verify the application profile

Configuration Guide for the BIG-IP WebAcceleratorTM System

Initial Configuration and Maintenance Tasks

Completing optional configuration tasks

Processing unmapped requests

To enable unmapped request processing

Using the MultiConnect feature