Applies To:

Show Versions Show Versions

Manual Chapter: Initial Configuration and Maintenance Tasks
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Before you configure the WebAccelerator system, you must complete the following tasks on the BIG-IP Local Traffic Manager.
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.
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.
After you have performed the initial configuration tasks on the BIG-IP Local Traffic Manager, you can begin configuration for the WebAccelerator system, by:
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.
1.
In the navigation pane, expand System and click General Properties.
3.
In the Address box, type an address for the NTP server.
4.
Click Add.
5.
Click Update.
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.
1.
In the navigation pane, expand WebAccelerator and click Class Profiles.
2.
Click Create.
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 section, verify that WebAccelerator system 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 check 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.
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 that you want the WebAccelerator system to which you want 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 AskF5 Technical Support web site, https://support.f5.com.
1.
In the navigation pane, expand Local Traffic, and then click Virtual Servers.
2.
Click Create.
3.
In the Name box, type a name for the virtual server.
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.
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:
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.
*.sales.siterequest.com maps to the following (all to the same destination host):
*siterequest.com maps to the following (all to the same destination host):
*.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 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.
You may select a pre-defined acceleration policy that is associated with your specific application publisher or you may use one of the two pre-defined general delivery acceleration policies. Both work well for most sites that use Java 2 Platform Enterprise Edition (J2EE) applications.
Level 1 Delivery
This pre-defined acceleration policy is compliant with HTML version 2.0. For this acceleration policy, the WebAccelerator system:
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 pre-defined 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.
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 planned your host map and chosen an acceleration policy, create the application profile using the following procedure.
1.
In the navigation pane, expand WebAccelerator and click Applications.
2.
Click Create.
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 pre-defined 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.
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 pre-defined 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.
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.
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.
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.
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:
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 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.
After you complete the essential configuration tasks, you can further customize by configuring the WebAccelerator system to:
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.
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.
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.
You specify a proxy server to forward the unmapped requests to, as described in step 5 of the following procedure, and you configure that proxy server to properly manage unwanted or unsanctioned requests.
1.
In the navigation pane, expand WebAccelerator and click Applications.
2.
3.
Check the Process requests for unmapped hosts box.
The screen refreshes and displays additional options.
4.
From the Policy list, select an acceleration policy for which you want to process unmapped requests.
5.
To forward unmapped host requests to a specific proxy server, select the button 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.
6.
Click Save.
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.
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.
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.
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 to use the domains you specified. For example:
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.
1.
In the navigation pane, expand WebAccelerator and click Applications.
3.
In the Hosts section 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 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.
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.
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 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.
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.
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.
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.
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 Applications.
2.
In the navigation pane, click Symmetric Deployment.
3.
Click Create.
4.
In the Name box, type a name for the central WebAccelerator system.
5.
If the WebAccelerator system uses network address translation (NAT) to communicate with other WebAccelerator systems in the data center, click the Use NAT Support box.
6.
In the Global Address box, type the public IP address that the WebAccelerator system uses to communicate with computers outside of the data center.
7.
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 9.
8.
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.
10.
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.
11.
Click Save.
After you configure a central WebAccelerator system for the symmetric deployment, you can create one or more remote WebAccelerator systems.
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.
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, click the Use NAT Support box.
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.
Click Remote.
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.
1.
In the navigation pane, expand WebAccelerator, and click Applications.
2.
In the navigation pane, click Symmetric Deployment.
4.
Click Save to save any changes you made, or click Cancel to return to the WebAccelerators screen.
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.
1.
From the command line of each remote WebAccelerator system in the symmetric deployment, type the following command:
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.
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.
After you complete the basic configuration required for the WebAccelerator system to process traffic, you can perform the following procedures, as required.
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.
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.
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)