8 Specialized Configurations

8.1.1 Task 1: Create Wallets

To support HTTPS for OracleAS Web Cache, you must create a wallet on the OracleAS Web Cache server for each supported site. Wallets are needed to support the following HTTPS requests:

• Browser requests using the HTTPS protocol for sites hosted by OracleAS Web Cache

• Administration, invalidation, and statistics monitoring requests to OracleAS Web Cache using the HTTPS protocol

• OracleAS Web Cache requests using the HTTPS protocol to origin servers

Each site that uses the HTTPS protocol requires at least one wallet. One wallet can be shared among all the HTTPS listening ports, or a separate wallet can be created for each HTTPS listening port.

For detailed instructions on creating a wallet, see the Oracle Application Server 10g Security Guide. The following provides the basic steps in creating a wallet for use by OracleAS Web Cache:

1. Invoke Oracle Wallet Manager:

   • On UNIX, run owm from $ORACLE_HOME/bin.

   • On Windows, choose Start > Programs > Oracle - Oracle_homename > Network Administration > Wallet Manager.

2. Create the wallet (Wallet > New), entering a password as prompted.

3. You are prompted whether or not to create a certificate request. Click Yes. Then, enter the information in the dialog box. For Common Name, specify the name or alias of the site that will be configured for HTTPS support.

4. Submit the certificate to a Certificate Authority (CA) for signature.

5. Import the CA’s root certificate into the wallet (Operations > Import Trusted Certificate).

6. Enable Auto-login, which enables PKI-based access to services without a password. Select the wallet and choose Wallet from the menu bar. Check Auto Login.

7. Save the wallet. Select the wallet and choose Wallet > Save.

8. When you receive the signed certificate from the CA, import it into the wallet (Operations > Import User Certificate) and save the wallet.

By default, wallets are stored in the following locations:

• /etc/ORACLE/WALLETS/user_name on UNIX

• %USERPROFILE%\ORACLE\WALLETS on Windows operating systems

  
  

  See Also: "Secure Sockets Layer (SSL) " "Wallet Cannot Be Opened " Oracle Application Server 10g Security Guide

  
  

8.1.2 Task 2: Configure HTTPS Listening Ports and Wallet Location for the Cache

To configure HTTPS protocol support between browsers and OracleAS Web Cache, you must configure an HTTPS listening port for OracleAS Web Cache:

1. From the navigator frame in OracleAS Web Cache Manager, select Ports > Listen Ports and click Add.

2. Specify the information for the port, selecting HTTPS for the Protocol.

3. Enable or disable client-side certificates.

   Select Require Client-Side Certificate to enable OracleAS Web Cache to require browsers to provide SSL certificates.

   A client-side certificate is a method for verifying the identity of the client. It binds information about the client user to the user’s public key and must be digitally signed by a trusted CA.

4. Enter the location of the wallet in the Wallet field.

   This wallet is used for browser requests for sites hosted by OracleAS Web Cache.

   By default, wallets are stored in /etc/ORACLE/WALLETS/user_name on UNIX and in %USERPROFILE%\ORACLE\WALLETS on Windows operating systems. Oracle Corporation recommends entering the location, even if the default is being used.

   If each site is configured with a separate wallet, the OracleAS Web Cache listening port can share the same wallet as specified in the Origin Server Wallet page (Origin Servers, Sites, and Load Balancing > Origin Server Wallet).

5. Click Submit.

8.1.3 Task 3: Configure HTTPS Operations Ports for the Cache

To configure HTTPS ports to listen for administration, invalidation, and statistics monitoring requests:

1. From the navigator frame, select Ports > Operations Ports and click Edit Selected.

2. Specify the information for the port, selecting HTTPS for the Protocol.

3. Enable or disable client-side certificates.

   Select Require Client-Side Certificate to enable OracleAS Web Cache to require browsers to provide SSL certificates.

   A client-side certificate is a method for verifying the identity of the client. It binds information about the client user to the user’s public key and must be digitally signed by a trusted CA.

4. In the Wallet field, enter the location of the wallet.

   This wallet is used for administration, invalidation, and statistics monitoring of HTTPS requests for sites hosted by OracleAS Web Cache.

   By default, wallets are stored in /etc/ORACLE/WALLETS/user_name on UNIX and in %USERPROFILE%\ORACLE\WALLETS on Windows. Oracle Corporation recommends entering the location, even if the default is being used.

   If each site is configured with a separate wallet, these ports can share the same wallet established for the OracleAS Web Cache listening port in "Task 2: Configure HTTPS Listening Ports and Wallet Location for the Cache" and specified in the Listen Ports page (Ports > Listen Ports) and the Origin Server Wallet page (Origin Servers, Sites, and Load Balancing > Origin Server Wallet.)

   "Task 8: Configure OracleAS Web Cache with Operations Ports" describes how to add a port.

5. Click Submit.

8.1.4 Task 4: Create a Site for HTTPS Requests

You must create a site that will accept HTTPS requests.

1. In the navigator frame, select Origin Servers, Sites, and Load Balancing > Site Definitions.

2. In the Site Definitions page, click Add Site.

3. Specify the information as described in "Task 10: Configure Web Site Settings " .

   In the Port field, enter the number of the HTTPS listening port. This site will use the wallet defined for that port.

   In the HTTPS Only Prefix field, enter the URL prefix for which only HTTPS requests will be served. If all traffic must be restricted to HTTPS, enter "/ " for the entire site.

4. Click Submit.

8.1.5 Task 5: Configure HTTPS Port and Wallet Location for the Origin Server

You can configure HTTPS protocol support between OracleAS Web Cache and origin servers. When you use the Oracle HTTP Server as the origin server, requests from an OracleAS Web Cache server configured with an HTTPS listening port are passed on a secure (SSL) connection. It is not necessary to configure an HTTPS port for an Oracle HTTP Server.

However, for other origin servers, you must configure an HTTPS port to secure the connection from OracleAS Web Cache to the origin server.

To configure HTTPS protocol support between OracleAS Web Cache and origin servers:

1. From the navigator frame, select Origin Servers, Sites, and Load Balancing > Origin Servers.

2. In the Origin Servers page, either click Add to add an origin server, or select an existing server and click Edit.

3. In the dialog box, specify the information for the origin server, selecting HTTPS for the Protocol. (See "Task 9: Configure Origin Server, Load Balancing, and Failover Settings " for information on configuring the origin server.)

4. Click Submit.

Then, you specify the location of the wallet for OracleAS Web Cache communication to the origin server.

This wallet manages OracleAS Web Cache authentication data, such as keys, certificates, and trusted certificates needed by the Secure Sockets Layer (SSL). By default, wallets are stored in /etc/ORACLE/WALLETS/user_name on UNIX and %USERPROFILE%\ORACLE\WALLETS on Windows.

If each site is configured with a separate wallet, HTTPS requests from OracleAS Web Cache to the origin server can share the same wallet as established for the OracleAS Web Cache listening ports. This is the default wallet.

Oracle Corporation recommends entering the location, even if the default is being used.

To specify the wallet location:

1. In the navigator frame, select Origin Servers, Sites, and Load Balancing > Origin Server Wallet.

   The Origin Server Wallet page appears.

2. Select the cache for which you want to modify wallet settings, and then click Edit Selected.

   The Edit Origin Server Wallet dialog box appears.

3. In the Wallet Directory field, enter the location of the wallet.

4. Click Submit.

8.1.6 Task 6: Create the Site-to-Server Mapping

You must map the site for HTTPS requests to the origin server:

1. In the navigator frame, select Origin Servers, Sites, and Load Balancing > Site-to-Server Mapping.

2. Create a mapping as described in "Map Sites to Origin Servers", specifying the site you created in "Task 4: Create a Site for HTTPS Requests".

3. Click Submit.

8.1.7 Task 7: (Optional) Require Client-Side Certificates

You can require that clients send certificates (client-side certificates) to the cache to verify the identity of the client.

With client-side certificates, the browser sends the certificate to the cache during the SSL handshake. Then, the server processes the request for the document. If the requested document is not stored in the cache, the cache forwards the request to the application Web server, a peer cache (in a cluster), or a subordinate cache (in a hierarchy). To transfer information about the client-side certificate to another cache or to the application Web server, OracleAS Web Cache adds HTTP headers to the request. The headers begin with the string SSL-Client-Cert.

Note the following points about using client-side certificates:

• In a simple configuration (client to cache to application Web server), the client sends the certificate to the cache during the SSL handshake. If the requested document is not stored in the cache, the cache forwards the request to the application Web server and transfers the client-side certificate information in headers to the application Web server. The application Web server recognizes the headers and responds to the request.

• In a cluster, the client sends the certificate to a cache cluster member during the SSL handshake. If the requested document is not stored in that cache, the cluster member requests it from a peer (the cluster member that owns the document). With client-side certificates, OracleAS Web Cache must be able to pass the client-side certificate information in headers to the peer cluster member, and the peer must be able to pass the headers to the application Web server.

• In an ESI hierarchical deployment, the browser sends the certificate to the subscriber cache in a hierarchy. That cache must be able to forward the certificate information in headers to a provider cache. However, with this configuration, the provider caches could inadvertently accept the certificate information in a header from a bogus entity. To prevent this, you must secure the provider caches, by methods such as installing them behind a firewall.

• If client-side certificates are required, but not provided by the client, OracleAS Web Cache returns an error: 403: Forbidden.

  
  

  Note: OracleAS Web Cache supports the use of client-side certificates with Oracle HTTP Server only. OracleAS Web Cache does not support client-side certificates with a distributed cache hierarchy because the security of the certificates cannot be guaranteed.

  
  

To use client-side certificates, you must enable an HTTPS listening port. If you have a cache cluster, you must enable HTTPS listening ports for all cluster members. In addition, take the following steps:

1. In the OracleAS Web Cache Manager navigator frame, select Ports > Listen Ports.

   The Listen Ports page is displayed.

2. Select the HTTPS port and click Edit.

3. In the Edit Listening Port dialog box, select Require Client-Side Certificate.

4. Click Submit.

5. If you have a simple configuration, not a cache cluster or a cache hierarchy, proceed to the next section, "Task 8: (Optional) Permit Only HTTPS Requests for a URL or Set of URLs".

6. If you have a cache cluster, you must prevent a cache from accepting the certificate information in HTTP headers from any source other than a peer cluster member. In addition, each cache must be able to pass the client-side certificate information in headers to the peer cluster member, and the peer must be able to pass them to the application Web server. To configure this behavior:

   1. In the navigator frame, select Properties > Security.

   2. In the Special Security Header Configuration section of the Security page, the value of the following must be NO (the default):

      Accept SSL client certificates encoded in SSL-Client-Cert HTTP headers
      
      

      If it is not, click Edit.

      The Special Security Header Configuration dialog box is displayed.

   3. Clear Accept SSL client certificates encoded in SSL-Client-Cert HTTP headers.

   4. Click Submit.

   5. In the Cluster Security Configuration section of the Security page, the value of the following must be YES:

      Route requests that contain SSL client certificates to cache cluster peers
      
      

      If it is not, click Edit.

      The Cluster Security Configuration dialog box is displayed.

   6. Select Route requests that contain SSL client certificates to cache cluster peers.

   7. Click Submit.

7. If you have an ESI cache hierarchy, a provider cache, must be able to accept the client-side certificate information in headers from the subscriber cache. To enable this behavior:

   1. In the navigator frame, select Properties > Security.

   2. In the Special Security Header Configuration section of the Security page, the value of the following must be YES:

      Accept SSL client certificates encoded in SSL-Client-Cert HTTP headers
      
      

      If it is not, click Edit.

      The Special Security Header Configuration dialog box is displayed.

   3. Select Accept SSL client certificates encoded in SSL-Client-Cert HTTP headers.

   4. Click Submit.

   5. If the subordinate caches are in a cluster, the subordinate caches must be able to pass the client-side certificate information in headers to the peer cluster member. In this case, in the Cluster Security Configuration section of the Security page, the value of the following must be YES:

      Route requests that contain SSL client certificates to cache cluster peers
      
      

      If it is not, click Edit.

      The Cluster Security Configuration dialog box is displayed.

   6. Select Route requests that contain SSL client certificates to cache cluster peers.

   7. Click Submit.

You can also specify that an entire site require client-side certificates:

1. In the navigator frame, select Origin Servers, Sites, and Load Balancing > Site Definitions.

2. In the Site Definitions page, select the site and click Edit Site.

3. In the Edit Site page, select Required in the Client-Side Certificate field.

4. Click Submit.

8.1.8 Task 8: (Optional) Permit Only HTTPS Requests for a URL or Set of URLs

You can restrict a URL or set of URLs for a site to permit only HTTPS requests.

To allow only HTTPS traffic for a URL or a set of URLs:

1. Configure Web site settings, as described in "Task 10: Configure Web Site Settings ".

2. In Step 2d, enter the URL or URL prefix.

   If all traffic must be restricted to HTTPS, enter "/" for the entire site.

8.1.9 Task 9: Restart OracleAS Web Cache

To apply changes, in the OracleAS Web Cache Manager main window, click Apply Changes.

Then, you must restart the cache or admin server processes, using the opmnctl utility or webcachectl utility (for standalone installations) on the computer on which OracleAS Web Cache software is installed and configured.

To use the opmnctl utility to restart both processes, enter the following command:

opmnctl startproc ias-component=WebCache

8.2.1 Configuring a Distributed Cache Hierarchy

In a distributed cache hierarchy, the central cache stores content from application Web servers, and the remote cache stores content from the central cache. The central cache acts as an origin server to the remote cache.

To configure a distributed cache hierarchy, perform the tasks in "Tasks for Setting Up OracleAS Web Cache " for each cache. When performing the tasks, take special care to perform the following:

1. Configure the correct origin server:

   • For the central cache, configure the central origin servers in the Origin Servers page (Origin Servers, Sites, and Load Balancing > Origin Servers).

   • For the remote caches, configure the central cache as the origin server in the Origin Server page.

2. Create the same site definition for both the central and remote caches in the Site Definitions page (Origin Servers, Sites, and Load Balancing > Site Definitions).

3. For both central and remote caches, map the site definition to the origin server (configured in Step 0) in the Site-to-Server Mapping page (Origin Servers, Sites, and Load Balancing > Site-to-Server Mapping):

   • For the central cache, map the site to the application Web server or proxy server.

   • For the remote cache, map the site to the central cache.

4. Route that network so that browser requests are forwarded to the nearest cache.

5. Optionally, ensure that the ClientIP address information that is forwarded to the cache and origin server is valid.

   
   

   See Also: "Ensuring That ClientIP Headers Are Valid"

   
   

When content from the central cache becomes invalid, an invalidation message is sent to its cache. In addition, the central cache propagates the invalidation message to the remote caches.

Table 8-1 shows the example settings for the deployment depicted in "Deploying a Distributed Cache Hierarchy".

8.3.1 Additional Hierarchy Configuration for a Cache Cluster

In a cache hierarchy, each cache cluster member acts as an independent cache. Invalidation messages are propagated from each central or provider cache cluster member to the respective remote or subscriber caches. This configuration can result in the same invalidation message being propagated multiple times by cache cluster members.

If your deployment uses a Load Balancer to distribute requests among cache cluster members, you can optionally configure the cache cluster members to act as one cache and to receive only one set of propagated invalidation messages.

To configure cache cluster members to act as one cache for the purposes of hierarchical caching:

1. Select a cache cluster member to represent the cache.

2. For each of the other cache cluster members, use a text editor to open the webcache.xml file.

3. Locate the CLUSTERINFO element.

4. Add the following subelements:

   <CLUSTERINFO NAME="CLUSTER_IP" VALUE="IP_address" /
   <CLUSTERINFO NAME="CLUSTER_NORM_PORT" VALUE="web_cache_listening_Port" /
   <CLUSTERINFO NAME="CLUSTER_INV_PORT" VALUE="web_cache_invalidation_port" /
   <CLUSTERINFO NAME="CLUSTER_INV_SSL" VALUE="SSL_version" /
   
   

   Table 8-3 describes how to enter values for the subelements.

   Table 8-3 CLUSTERINFO Subelements

   Subelement	Description
   CLUSTER_IP	Enter the IP address of the cache.
   CLUSTER_NORM_PORT	Enter the listening port of the cache. See Also: "Task 6: Configure OracleAS Web Cache with Listening Ports for Incoming Browser Requests"
   CLUSTER_INV_PORT	Enter the invalidation port of the cache. See Also: "Task 8: Configure OracleAS Web Cache with Operations Ports"
   CLUSTER_INV_SSL	If the invalidation port is configured for HTTPS, configure the correct SSL version: NONE for HTTP-only requests (default) SSL for HTTPS requests supporting SSL version 1.0 SSLV2 for HTTPS requests supporting SSL version 2.0 SSLV3 for HTTPS requests supporting SSL version 3.0 SSLV3_V2H for HTTPS requests supporting either SSL version 2.0 or 3.0

   
   

   For example, if a cache cluster has members webche1-host, webche2-host, and webche3-host, you cans configure webche2-host, and webche3-host with settings for webche1-host as follows:

   <CLUSTERINFO NAME="CLUSTER_IP" VALUE="130.35.45.41" />
   <CLUSTERINFO NAME="CLUSTER_NORM_PORT" VALUE="4000" />
   <CLUSTERINFO NAME="CLUSTER_INV_PORT" VALUE="4001" />
   <CLUSTERINFO NAME="CLUSTER_INV_SSL" VALUE="NONE" />
   
   

   This configuration enables the cache cluster to acts as one logic cache and only webche1-host to receive the propagated invalidation messages.

5. Restart OracleAS Web Cache with the following command:

   opmnctl restartproc ias-component=WebCache
   

8.4.1 Task 1: Configure Cache Cluster Settings

To configure the settings for a cache cluster:

1. In the navigator frame, select Properties > Clustering.

   The Clustering page appears. The General Cluster Information section displays the default clusterwide values for failover and invalidation propagation. The Cluster Members table displays the current cache (the cache to which you are connected) as the only cluster member. OracleAS Web Cache ignores the cluster information if there is only one cluster member.

2. In the General Cluster Information section of the Clustering page, click Edit.

   The Edit General Cluster Information dialog box appears.

3. In the Cluster Name field, enter a name for the cluster.

4. In the Failover Threshold field, enter the number of allowed consecutive request failures before OracleAS Web Cache considers another cache cluster member to have failed.

   OracleAS Web Cache considers a request to another cache cluster member to have failed if:

   • There are any network errors

   • The HTTP response status code is either less than 100, or is one of the following: 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, or 504 Gateway Timeout.

   For each failed request, OracleAS Web Cache increments the failure counter for that cluster member. This counter is kept separately by each cluster member. When a request is successfully processed by a cluster member, OracleAS Web Cache resets the failure counter.

   When the failover threshold is met, OracleAS Web Cache considers the cache cluster member to have failed. OracleAS Web Cache recalculates the relative capacity of the remaining cache cluster members. It then reassigns ownership of cache content.

   When a cache cluster member is down, OracleAS Web Cache starts polling the cache cluster member. It does this by sending requests to the URL specified in the Ping URL field. When OracleAS Web Cache receives a success response from the cache cluster member, it considers that cache cluster member to be up again. It recalculates the relative capacity of the cache cluster members and it reassigns ownership of cache content.

5. In the Ping URL field, enter the URL that cache cluster members will use to attempt to contact a cache cluster member that has reached its failover threshold.

   Use a URL that is cacheable and that you can guarantee is stored in each cache. The default is "/".

6. In the Ping Interval field, enter the time, in seconds, between attempts by a cluster member to reach the failed cluster member. The default, 10 seconds, is a reasonable interval for most situations.

7. In the Propagate Invalidation field, select Yes or No to specify whether or not you want all invalidation requests from any cache cluster member to be propagated to other cache cluster members.

8. Click Submit.

9. In the Cluster Members table of the Clustering page, default values are displayed for the current cache. Select the cache and click Edit Selected.

   The Edit Cluster Member dialog box appears.

10. In the Cache Name field, enter a name for the OracleAS Web Cache instance. The name must be unique from the names of other caches in the cache cluster.

11. By default, the Host Name field contains the host name of the node on which OracleAS Web Cache is installed. Usually, you do not need to modify this field.

12. By default, the Oracle Home field contains the file specification for the Oracle home in which OracleAS Web Cache is installed. Usually, you do not need to modify this field. Note that the combination of Host Name and Oracle Home must be unique in a cache cluster.

13. In the Capacity field, enter the number of concurrent incoming connections from other cache cluster members that OracleAS Web Cache can sustain.

    This field is used in two different ways:

    • As the absolute capacity for the number of concurrent incoming connections to this cache cluster member from all other cache cluster members.

      The connections are used to receive requests for owned content from other cache cluster members. The number of connections are divided among the other cluster members. For example, in a three-cache cluster, if the capacity of Cache_A is 50, Cache_B can open 25 connections to Cache_A and Cache_C can open 25 connections to Cache_A.

      More connections are used when another cache cluster member contains little or no data in its cache, such as when it is initially started, when it recovers from a failure, or after invalidation. During this time, the cluster member sends many of the requests to its peers, the owners of the content. In most cases, these requests are satisfied more quickly than requests to the origin server. Having a higher number of connections increases performance during this time and shortens the time it takes to fully load the cache. After a cache is fully loaded, fewer of the connections are used. There is no overhead for unused connections.

    • As the relative capacity of the cache cluster member.

      The capacity of a cache cluster member is weighted against the total capacity of all active cache cluster members. When you set the capacity, OracleAS Web Cache assigns a percentage of the ownership array to the cluster member, indicating how much of the cached content will be owned by the cluster member. The percentage is calculated using the following formula:

      cluster_member_capacity / total_capacity_of_all_active_cluster_members
      
      

      For example, if cache cluster member Cache_A has a capacity of 100 and cache cluster member Cache_B has a capacity of 300, for a total capacity of 400, Cache_A is assigned 25 percent of the ownership array and Cache_B is assigned 75 percent of the ownership array. That means that Cache_A owns 25 percent of the cached content.

      Note that in calculating the relative capacity, OracleAS Web Cache considers the capacity of active cluster members; it does not consider the capacity of cluster members that it has determined to have failed.

    In most cases, a capacity of 100 is a reasonable number to use as a starting point.

    If you assign a capacity of 0 to a cluster member, that cluster member will not receive requests from other cluster members. However, that cluster member will forward requests to other cluster members, the owners of the content.

    If you assign a capacity of 0 to all cluster members, no requests will be forwarded between cluster members. With this setup, you can propagate the configuration and invalidation across all cache cluster members, simplifying the administration of many caches. See "Configuring Administration and Invalidation-Only Clusters" for more information.

14. Click Submit.

    You now have one cache, the current cache, in the cluster. However, the cluster information is ignored until you have more than one OracleAS Web Cache instance in the cluster.

8.4.2 Task 2: Add Caches to the Cluster

Before you can add a cache to the cluster, the following conditions must be met:

• The cache must exist and must be started. See "Task 12: Apply Changes and Restart OracleAS Web Cache" for information about starting OracleAS Web Cache.

• The administrator password of the cache to be added must be the same as the administrator password of the cache to which you are connected. If it is different, you must connect to the cache’s admin server and modify the administration password, as described in "Task 2: Modify Security Settings ".

To add another cache to the cluster:

1. In the navigator frame, select Properties > Clustering.

   The Clustering page appears.

2. In the Cluster Members section of the Clustering page, click Add.

   The Add Cache to Cluster dialog box appears.

3. In the Host Name field, enter the host name of the cache to be added to the cluster.

4. In the Admin Port field, enter the administration port for the cache to be added to the cluster.

   The administration port is the listening port for administrative requests.

5. In the Protocol for Admin Port field, select either HTTP or HTTPS to accept HTTP or HTTPS browser requests.

6. In the Cache Name field, enter a name for the cache. The name must be unique from the names of other caches in the cache cluster.

7. In the Capacity field, enter the number of concurrent incoming connections from other cache cluster members that OracleAS Web Cache can sustain.

   
   

   See Also: Step 13 in "Task 1: Configure Cache Cluster Settings" for more information about capacity

   
   

8. Click Submit.

   The cache is now part of the cluster and is listed in the Cluster Member table.

9. To add more OracleAS Web Cache instances to the cache cluster, repeat Steps 2 through 8.

10. When you have completed adding members to the cache cluster, click Apply Changes.

OracleAS Web Cache adds the cache-specific information from the new cache cluster members to the cluster configuration.

You can add more OracleAS Web Cache instances to the cluster at any time by choosing Add. You can modify the settings for a cache cluster member by choosing Edit Selected. You can delete a cache cluster member, other than the current cache, by choosing Delete Selected.

8.4.3 Task 3: Enable Tracking of Session Binding

In a cache cluster, all cache cluster members must be able to determine which origin server established the session, although the request was routed originally through only one cache cluster member. To configure session binding in a cache cluster, you specify that OracleAS Web Cache adds a cookie that tracks session information so that it can be read by all cluster members. OracleAS Web Cache includes a Set-Cookie response-header in the response so that subsequent requests from the client include the cookie. The cookie provides information so that any of the cluster members can resolve the binding regardless of which cache handled the initial request.

8.4.4 Task 4: Propagate the Configuration to Cluster Members

When you modify the cluster and click Apply Changes, OracleAS Web Cache adds the cache-specific information from the new cache cluster members to the configuration. For those changes to take affect in all cluster members, you must propagate the configuration and restart the cache server process of the cluster members.

To propagate the configuration to new cluster members:

1. In the navigator frame, select Operations > Cache Operations.

   The Cache Operations page appears. The Operation Needed column indicates the caches to which the configuration should be propagated.

2. Propagate the configuration to all cache cluster members:

   1. Select All caches in the Operate On field.

   2. Select an Interval of Immediate. (No other interval is allowed for propagation.)

   3. Click Propagate.

   (Alternatively, you can propagate the configuration to one cluster member at a time. Click Selected cache in the Operate On field, and then click Propagate.)

   When the operation completes, the Operation Needed column in the Cache Operations page indicates the cluster members that need to be restarted.

3. Stop and restart all cluster members:

   1. Select All caches in the Operate On field.

   2. Select an Interval to stagger the time that operation begins on the caches, and then click Restart.

   (Alternatively, you can restart one cluster member at a time.) Choose Selected cache in the Operate On field and then click Restart.)

When the operation completes, the Operation Needed column in the Cache Operations page indicates that no operations are needed. The cache cluster is ready to use.

8.4.5 Removing Caches from a Cluster

To remove a cache from a cluster, you must not only make sure that remaining cluster members no longer include that cache in cluster, but that the removed cache no longer considers itself to be part of the cluster. To remove a cache from a cluster, take the following steps:

1. Enter the URL for the OracleAS Web Cache Manager of one of the caches in cluster, but not the cache that you want to remove from the cluster. If prompted, enter the user name and password for the ias_admin or administrator user.

2. In the navigator frame, select Properties > Clustering.

3. In the Cluster Members section of the Clustering page, select the cache you want to remove from the cluster and click Delete Selected.

4. In the OracleAS Web Cache Manager main window, click Apply Changes.

5. Propagate the change to the other remaining cache cluster members:

   1. In the navigator frame, select Operations > Cache Operations.

   2. Select All caches in the Operate On field.

   3. Select an Interval of Immediate.

   4. Click Propagate.

      The change is propagated to all the remaining cluster members, but not to the removed cluster member.

6. Restart all cluster members:

   1. In the Cache Operations page, select All caches in the Operate On field.

   2. Select an Interval to stagger the time that operation begins on the caches, and then click Restart.

   All remaining caches in the cluster no longer consider the removed cache to be part of the cluster. However, the removed cache still considers itself to be part of the cluster. To remedy that situation, take the next steps.

7. Enter the URL for the OracleAS Web Cache Manager of the cache you removed from the cluster. Enter the username and password for the ias_admin or administrator user.

8. In the navigator frame, select Properties > Clustering.

   The Clustering page appears. The Cluster Members section still shows all members of the cluster.

9. In the Cluster Members section of the Clustering page, select each cache except the current one, and click Delete Selected. Repeat until only the current cache remains in the Cluster Members list.

10. In the OracleAS Web Cache Manager main window, click Apply Changes.

11. In the navigator frame, select Operations > Cache Operations.

12. Select the cache and click Restart.

8.4.6 Configuring Administration and Invalidation-Only Clusters

You can configure a cluster that supports propagating the configuration and invalidation requests across all cache cluster members, but that does not forward requests between cache cluster members. That is, in processing requests, each cluster member acts as an individual cache and does not request documents from its peer cluster members. However, configuration changes and invalidation requests can be propagated to cluster members.

This configuration can be used to simplify administration of many caches. It may be needed in a cluster where members are separated by a firewall. For example, you can have a cluster where two caches are located on either side of a firewall that separates the intranet from internet. (The network settings of such a setup—of sending internet traffic to one cache and intranet traffic to another—is beyond the scope of this document.)

To manage these caches as a cluster and avoid sharing contents between the caches, take the following steps:

1. Create a cluster and add members to it as discussed in "Task 1: Configure Cache Cluster Settings" and "Task 2: Add Caches to the Cluster", with the exception noted in the following step.

2. For each cluster member, set the capacity to 0. (Select Properties > Clustering. Then, select a cluster member and click Edit. In the Edit Cluster Member dialog box, set the Capacity to 0.)

3. Propagate the configuration to all cluster members, as described in "Task 4: Propagate the Configuration to Cluster Members ".

8.6.1 Enabling End-User Performance Monitoring

To enable End-User Performance Monitoring for a cache or a site, take the following steps:

1. In the navigator frame of OracleAS Web Cache Manager, select Logging and Diagnostics > End-User Performance Monitoring.

2. You can enable monitoring for a particular cache or for an entire site.

   • To enable monitoring for a particular cache, in the End-User Performance Monitoring page, select the cache from the Cache-Specific End-User Performance Monitoring section. Then, click Enable.

   • To enable monitoring for the entire site, in the End-User Performance Monitoring page, select the site from the Site-Specific End-User Performance Monitoring section. Then, click Enable.

   Note the following:

   • If you enable monitoring for a specific cache, but you disable monitoring for a site, monitoring is performed for all the sites in that cache node except for the site for which it is disabled.

     If a request does not match any of the sites for which monitoring is enabled, the request will not be monitored.

   • If you disable monitoring for a cache, monitoring is not performed for any of the sites of that cache node.

   • For a site, you can specify end-user performance monitoring rules.

   When end-user performance monitoring is enabled for a cache, OracleAS Web Cache and Oracle Enterprise Manager monitor all requests that are routed through the cache. When end-user performance monitoring is enabled for a site, OracleAS Web Cache and Oracle Enterprise Manager monitor all of the Web pages on your Web site and provide you with information about how the pages are responding to customer requests. Using Oracle Enterprise Manager, you can sort this information by URL, region, domain, visitor, and Web server.

3. Optionally, select URLs to monitor or not monitor by creating site-specific monitoring rules as described in "Selecting URLs to Monitor".

4. Configure OracleAS Web Cache to use the Web Cache Log Format (WCLF) access log format, as described in "Configuring Access Logs".

5. Start end-user performance monitoring. From Oracle Enterprise Manager, on the Configure End-User Monitoring page, select Collect Data for End-User Monitoring. Then, specify an interval for collection of the data.

8.6.2 Selecting URLs to Monitor

Using the OracleAS Web Cache Manager, for each site, you can further refine which Web pages are monitored, by specifying regular expressions or path substrings. Take the following steps:

1. In the navigator frame, select Logging and Diagnostics > End-User Performance Monitoring.

2. In the Site-Specific End-User Performance Monitoring section of the End-User Performance Monitoring page, select the site, then click View.

3. To add a site-specific rule, click Create Site-Specific Rule.

   The Create End-User Performance Monitoring Rule page is displayed.

4. In the URL Expression field, specify the URL expression. Note the following information, which is dependent on the Expression Type selected:

   • Path Substring: Enter a path substring.

     The substring is interpreted literally, including reserved regular expression characters. These characters include periods (.), question marks (?), asterisks (*), brackets ([]), curly braces ({}), carets (^), dollar signs ($), and backslashes (\).

     For example, if you enter a substring of down, any of the following URLs match the expression:

     http://www.company.com/wireless/downloads/index.htm
     http://www.company.com/support/updown.htm
     http://www.company.com/support/shutdown_gdlines.htm
     
     

   • Regular Expression: Enter the regular expression. Remember to use "^" to denote the start of the URL and "$" to denote the end of the URL.

     Regular expression syntax is based on the POSIX 1003 extended regular expressions for URLs, as supported by Netscape Proxy Server 2.5.

     When using POSIX regular expression, keep the following syntax rules in mind:

     • If these characters are not used, POSIX assumes a substring match. For example, ^/a/b/.*\.gif$ will match GIF files under /a/b or any of its subdirectories. /a/b/.*\.gif, on the other hand, could match /x/y/a/b/c/d.gift.

     • Use a period (.) to match any one character

     • Use a question mark (?) to match zero or one occurrence of the character that it follows.

     • Use an asterisk (*) to match zero or more occurrences of the pattern that it follows.

     • Use a backslash (\) to escape any special characters, such as periods (\.), question marks (\?), or asterisks (\*).

     For example, to monitor all URLs beginning with /machine/doc and ending in .gif, enter the following expression:

     ^/machine/doc/.*\.gif$
     
     

5. From the list in the Expression Type column, select one of the following options:

   • Path Substring: Applies the monitoring rule to objects matching a substring of a path

   • Regular Expression: Applies the monitoring rule to objects matching regular expression syntax

6. For Monitoring Policy, select Monitor or Don’t Monitor for the rule.

7. Click Submit.

8. To create another monitoring rule, click Edit, Insert Above, or Insert Below. Then, repeat Steps 4 through 7.

9. If you have more than one monitoring rule, you can use the Move Up and Move Down buttons on the End-User Performance Monitoring page to prioritize the rules. Higher priority rules are processed first. The highest priority rule appears first in the list. The lower the number listed in the priority column, the higher the priority. For example, the highest priority rule is assigned a priority of one (1).

   For a regular expression that matches documents or a subset of documents that you do not want to monitor, give the rule that specifies Don’t Monitor a higher priority than the rule that specifies Monitor. For example, if you want all URLs containing /cec/cstage?ecaction=ecpassthru to be monitored except for /cec/cstage?ecaction=ecpassthru2, you would enter the rules in the following order:

   1. ^/cec/cstage\?ecaction=ecpassthru2, Don’t Monitor

   2. ^/cec/cstage\?ecaction=ecpassthru.*, Monitor

   If the order were reversed, all documents starting with /cec/cstage?ecaction=ecpassthru would be monitored, including /cec/cstage?ecaction=ecpassthru2.

8.7.1 Configuring Microsoft Network Load Balancing

On certain Windows platforms, you can use the Microsoft Network Load Balancing (NLB) component of the operating system instead of a hardware load balancer. NLB is part of the Microsoft clustering offerings and is available on the following platforms:

• Windows 2000 Advanced Server

• Windows 2000 Datacenter Server

• Windows 2003 (all editions)

You configure the hosts as a cluster and you configure the operating system to provide load balancing. Then, you configure NLB for hosts that are running Web Cache in a cache cluster, taking the following steps for each host:

1. Choose Start > Settings > Network and Dial-up Connections.

2. Select the network adapter. Then, right-click and select Properties.

3. In the Properties dialog box, select Network Load Balancing. Then, click Properties.

4. In the Cluster Parameters tab of the Network Load Balancing Properties dialog box, take the following steps:

   1. For Primary IP Address, enter the virtual IP address to be shared by all members of the cluster.

   2. For Subnet mask, enter the subnet mask for the virtual IP address.

   3. For Full Internet Name, enter the full internet name for the virtual IP address.

   4. Note the Network Address, which is a generated address.

   5. For Multicast support, check enabled.

   6. Optionally, enter a Remote password and enable Remote control.

5. Select the Host Parameters tab and take the following steps:

   1. For Priority, enter an integer between 1 and 32. The lower the number, the higher the priority. Priority establishes the default handling priority among hosts for requests that are not load-balanced by port rules. (See Step 6 for information about configuring port rules.)

   2. For Initial cluster state, check active. This specifies that this host should be included in the cluster array immediately upon Windows startup.

   3. For Dedicated IP address, enter the IP address of this host.

   4. For Subnet mask, enter the subnet mask of this host.

6. Select the Port Rules tab, and take the following steps:

   1. For Port Range, to balance the load from all client requests with a single port rule, use the default port range (0-65535). Use multiple port rules if different applications require different protocols, filtering modes, or affinity.

   2. For Protocols, select TCP. If your application uses software that requires UDP, select Both.

   3. For Filtering Mode, select Multiple Hosts.

   4. For Affinity, you can select one of three options. None results in load balancing of all requests across all hosts. Single results in all requests from a particular client being processed by the same host. Use this option to maintain session state. Class C results in all client requests from a TCP/IP class C address range being processed by the same host.

   5. For Load Weight, either enter a percentage of the load to be handled by the host or select equal.

   Note that Port Rules must be identical for all hosts in the cluster.

For more information about Microsoft Network Load Balancing, see the Microsoft documentation at:

http://www.microsoft.com