-
CSS Content Load-Balancing Configuration Guide (Software Version 7.40)
-
Index
-
Preface
-
Content Load-Balancing Overview
-
Configuring Flow and Port Mapping Parameters
-
Configuring Services
-
Configuring Service, Global, and Script Keepalives
-
Configuring Source Groups for Services
-
Configuring Loads for Services
-
Configuring Dynamic Feedback Protocol for Server Load Balancing
-
Configuring Owners
-
Configuring Content Rules
-
Configuring Sticky Parameters for Content Rules
-
Configuring HTTP Header Load Balancing
-
Configuring Caching
-
Configuring Content Replication
-
Table Of Contents
Service Configuration Quick Start
Assigning an IP Address to the Service
Specifying an HTTP Redirect String
Prepending "http://" to a Redirect String or a Domain
Configuring an Advanced Load-Balancing String
Configuring a Service HTTP Cookie
Configuring Weight and Graceful Shutdown
How the CSS Accesses Server Types
Bypassing Content Rules on Caches
Configuring Network Address Translation for Transparent Caches
Configuring a Service to Bypass a Cache Farm
Configuring Maximum TCP Connections
Configuring Keepalives for a Service
Showing Service Configurations
Clearing Service Statistics Counters
Configuring Services
This chapter describes how to configure content services. Information in this chapter applies to all CSS models except where noted.
•
Service Configuration Quick Start
•
•
•
•
•
•
•
•
•
•
•
•
•
For an overview of the association between services, owners, and content rules, see Chapter 1, Content Load-Balancing Overview.
Note
Service Configuration Quick Start
Table 3-1 provides a quick overview of the basic steps required to configure a service. Each step includes the CLI command required to complete the task. For a complete description of each feature and all the options associated with the CLI commands, see the sections following Table 3-1.
The following running-configuration example shows the results of entering the commands in Table 3-1.
!************************** SERVICE **************************service serv1ip address 10.3.6.2activeservice serv2ip address 10.3.6.1activeCreating a Service
A service can be a destination location or entity that contains and provides Internet content (for example, a server, an application on a server such as FTP, or streaming audio). A service has a name that is associated with an IP address and optionally, a protocol and a port number.
By creating a service, you identify the service and enable the CSS to recognize it. You can then apply content rules to services that allow the CSS to:
•
•
Enter a service name from 1 to 31 characters. For example, to create service serv1, enter:
(config)# service serv1The CSS transitions into the newly created service mode.
(config-service[serv1])#To delete an existing service, enter:
(config)# no service serv1Delete service <serv1>, [y/n]:yAssigning an IP Address to the Service
To enable the CSS to direct requests for content to the appropriate service, you must assign an IP address or range of IP addresses to a service. Assigning an IP address to a service identifies the service to the CSS. When the CSS receives a request for content, it translates the VIP (and potentially, the port) to the service IP address (or addresses) and port.
For example, to assign an IP address to serv1, enter:
(config-service[serv1])# ip address 172.16.1.1To restore a service IP address to the default of 0.0.0.0, enter:
(config-service[serv1])# no ip address
Note
•
•
•
You must configure these services with a keepalive type of none.
The range option allows you to specify a range of IP addresses starting with the IP address you specified using the ip address command. Enter a number from 1 to 65535. The default range is 1. For example, if you enter an IP address of 172.16.1.1 with a range of 10, the IP addresses range from 172.16.1.1 through 172.16.1.10.
For example, enter:
(config-service[serv1])# ip address 172.16.1.1 range 10When using the ip address range command, use IP addresses that are within the subnet you are using. The CSS does not arp for IP addresses that are not on the circuit subnet. For example, if you configure the circuit for 10.10.10.1/24 and configure the VIP range as 10.10.10.2 range 400, the CSS will not arp for any IP addresses beyond 10.10.10.254. Using the same example only with a VIP range of 200, the CSS will arp for all IP addresses in the range.
Note
For the CSS to forward requests to a service on any of the addresses in a range, the CSS must successfully arp for the first address in the range. This behavior is independent of keepalives.
Specifying a Port
The TCP or UDP destination port number is associated with a service. Use the port command to specify a service TCP/UDP port number or range of port numbers. Enter the port number as an integer from 0 to 65535. The default is 0 (any).
For example, enter:
(config-service[serv1])# port 80To specify a port to be used for keepalives, use the service mode keepalive port command.
Use the range option to specify a range of port numbers starting with the port number you specified using the port command. Enter a range number from 1 to 65535. The default range is 1. For example, if you enter a port number of 80 with a range of 10, the port numbers will range from 80 through 89. You can use the port range command only on local (default) services.
For example, enter:
(config-service[serv1])# port 80 10To set the port to the default of 0 (any), enter:
(config-service[serv1])# no portSpecifying a Protocol
By default setting, the CSS uses any IP protocol for the service. To specify the service IP protocol that the service is to use, use the protocol command. The options for this command are:
•
•
For example, enter:
(config-service[serv1])# protocol tcpTo set the protocol to the default of any, enter:
(config-service[serv1])# no protocolSpecifying a Domain Name
The CSS uses the configured domain name in the redirect message as the new location for the requested content. The CSS prepends the domain name to the requested URL. If the domain name is not configured, the CSS uses the domain in the host-tag field from the original request. If no host tag is found, the CSS uses the service IP address to generate the redirect. Use the domain command to specify the domain name that will be prepended to a requested piece of content when an HTTP redirect service generates a "302 object moved" message for the service.
Note
Note
Note
Enter the service domain name as an unquoted text string with no spaces and a maximum length of 64 characters.
Note
For example, enter:
(config-service[serv1])# domain www.arrowpoint.comor
(config-service[serv1])# domain 172.16.3.6To clear the redirect domain for this service, enter:
(config-service[serv1])# no domain www.arrowpoint.comor
(config-service[serv1])# no domain 172.16.3.6Specifying an HTTP Redirect String
The CSS uses the entire configured redirect string as the new location for the requested content. If no string is configured, the CSS prepends the domain configured with the (config-service) domain command to the original request. If neither the redirect string nor the domain name is configured, the CSS uses the domain in the host-tag field from the original request combined with the requested HTTP content. If no host tag is found, the CSS uses the IP address of the service to generate the redirect.
Use the redirect-string command to specify an HTTP redirect string that the CSS uses when an HTTP redirect service generates a "302 object moved" message for the service. You can configure a redirect string only on a service of type redirect.
Note
The syntax for this service mode command is:
redirect-string string
Enter the HTTP redirect string as a quoted or an unquoted text string with no spaces and a maximum of 252 characters.
For example, enter:
(config-service[serv1])# redirect-string www.arrowpoint.comTo remove the redirect string from the service, enter:
(config-service[serv1])# no redirect-string www.arrowpoint.comPrepending "http://" to a Redirect String or a Domain
By default, the CSS prepends "http://" to a redirect string or domain. To disable prepending "http://" to a redirect string or domain configured on a service, enter:
(config-service[serv1])# no prepend-httpUse the prepend-http command to prepend "http://" to a redirect string or domain configured for a service.
For example, enter:
(config-service[serv1])# prepend-httpConfiguring an Advanced Load-Balancing String
You can specify an advanced load-balancing method for a content rule that includes stickiness. A content rule is "sticky" when additional sessions from the same user or client are sent to the same service as the first connection, overriding normal load balancing. By default, the advanced balancing method is disabled.
To specify an advanced load-balancing string for a service, use the string command. Use this command with the advanced load-balancing methods url, cookie, or cookieurl. For information on advanced load-balancing methods, refer to Chapter 10, Configuring Sticky Parameters for Content Rules.
Enter a string from 1 to 15 characters. For example, enter:
(config-service[serv1])# string 172.16.3.6To remove a string from a service, enter:
(config-service[serv1])# no stringConfiguring a Service HTTP Cookie
You can specify an advanced load-balancing method for a content rule that includes stickiness. A content rule is "sticky" when additional sessions from the same user or client are sent to the same service as the first connection, overriding normal load balancing. By default, the advanced balancing method is disabled.
If you are using advanced-balance cookies, url, or cookieurl to match an exact string, you must configure the unique string that you want to use for matching each server. Use the string command to specify the HTTP cookie for the service. The syntax for this service mode command is:
string cookie_name
Enter the cookie_name as an unquoted text string with no spaces and a maximum of 15 characters.
For example, enter:
(config-service[serv1])# string userid3217To remove the cookie for a service, enter:
(config-service[serv1])# no stringFor information on configuring sticky on the CSS, refer to Chapter 10, Configuring Sticky Parameters for Content Rules.
Configuring Weight and Graceful Shutdown
The CSS uses this weight when you configure an ACA or weighted roundrobin load balancing method on a content rule. By default, all services have a weight of 1. A higher weight will bias flows toward the specified service. For background information on ACA load-balancing decisions based on server weight, see the "Using ArrowPoint Content Awareness Based on Server Load and Weight" section later in Chapter 6, Configuring Loads for Services.
To specify the relative weight of the service, use the weight command in service mode. To set the weight for a service, enter a number from 0 (graceful shutdown) to 10. The default is 1.
If you want to perform a graceful shutdown of an overloaded service or take a service offline for maintenance, specify a weight of 0 so no new connections, except the connections for existing sticky sessions, will be directed to the service. Over time, as existing sticky sessions complete, the load on the service begins to diminish. Changing the weight from 0 to a value between 1 and 10 causes the service to be brought back into rotation for all load balancing methods.
Note
The CSS recognizes content requests that include a location cookie as part of a sticky session. Therefore, even if you add a service with a configured weight of zero as a location service to a content rule, the CSS continues to direct to that service any requests that contain location cookies originating from the service.For example, to specify a weight of 2, enter:
(config-service[serv1])# weight 2To specify a weight of 0 to gracefully shut down a specific service, enter:
(config-service[serv1])# weight 0To restore the weight to the default of 1, enter:
(config-service[serv1])# no weightIf you configure a weight on a service using the weight command, and there is a configured Dynamic Feedback Protocol (DFP) agent for the service, the configured weight for the DFP agent takes precedence over the weight configured on a service (weighted round-robin load-balancing method only).
When you add a service to one or more content rules, the CSS applies the service weight, as configured in service mode, to each content rule as a server-specific attribute. To specify a content rule-specific server weight (assuming the content rule is using a weighted load-balancing method), use the weight option of either the add service command. These two commands override the server-specific weight and apply only to the content rule to which you add the service. For information on using the add service command, see the "Specifying a Service Weight" section in Chapter 9, Configuring Content Rules.
Specifying a Service Type
By default, the service type is local. Use the type command to specify the type for a service. The syntax and options for this service mode command are:
•
Note
•
•
•
When you add a type redirect service to a content rule, you must also configure a URL to match on the content. For example, "/*" or "/vacations.html".
•
•
•
•
•
–
–
For more information on configuring SSL termination, refer to the
Cisco Content Services Switch SSL Configuration Guide.•
–
–
For more information on configuring a back-end SSL server, refer to the
Cisco Content Services Switch SSL Configuration Guide.•
–
–
For more information on configuring an SSL initiation server, refer to the
Cisco Content Services Switch SSL Configuration Guide.•
For example, to enable the CSS to redirect content requests for serv1, specify redirect in the serv1 content rule:
(config-service[serv1])# type redirectTo restore the service type to the default setting of local, enter:
(config-service[serv1])# no typeHow the CSS Accesses Server Types
When you configure a Layer 3 or Layer 4 content rule, the rule hits the local services. If:
•
•
Redirect services and redirect content strings cannot be used with Layer 3 or Layer 4 rules because they use the HTTP protocol.
When you configure a Layer 5 content rule, the CSS directs content requests to local services. If:
•
•
•
For information on adding a service to a content rule or adding primary and secondary sorry servers, see Chapter 9, Configuring Content Rules.
Configuring Service Access
When a service offers publishing services, you must associate an FTP access mechanism for moving content during publishing, subscribing, and demand-based replication activities. Use the access command to associate an FTP access mechanism with a service. You must use this command for each service that offers publishing services. This command is optional for subscriber services; the subscriber service inherits the access mechanism from the publisher.
When you use this command to associate an FTP access mechanism with a service, the base directory of an existing FTP record becomes the tree root. To maintain coherent mapping between WWW daemons and FTP daemons, make the FTP access base directory equivalent to the WWW daemon root directory as seen by clients. For information on creating an FTP record, refer to the (config) ftp-record command in the Cisco Content Services Switch Administration Guide.
Enter the name of the existing FTP record as an unquoted text string with no spaces.
For example, enter:
(config-service[serv1])# access ftp arrowrecordTo remove a service access mechanism, enter:
(config-service[serv1])# no access ftpBypassing Content Rules on Caches
By default, no content rules are applied to requests from a proxy or transparent-cache type service. Use the cache-bypass command to prevent the CSS from applying content rules to requests originating from a proxy or transparent-cache type service when it processes the requests.
Note
For example, enter:
(config-service[serv1])# cache-bypassTo allow the CSS to apply content rules to requests from a proxy or transparent-cache type service, enter:
(config-service[serv1])# no cache-bypassConfiguring Network Address Translation for Transparent Caches
By default, destination Network Address Translation (NAT) for the transparent cache service type is disabled. Use the transparent-hosttag command to enable destination NAT for the transparent cache service type.
Currently, you can use the transparent-hosttag command only with a CSS operating in a Client Side Accelerator (CSA) environment. For details on CSA, refer to the Content Services Switch Global Server Load-Balancing Configuration Guide.
Note
For example, enter:
(config-service[serv1])# transparent-hosttagTo disable destination NATing for the transparent cache service type, enter:
(config-service[serv1])# no transparent-hosttagConfiguring a Service to Bypass a Cache Farm
By default, the CSS bypasses cache for non-cacheable content. Use the bypass-hosttag command to allow the CSA on the CSS to bypass a cache farm and establish a connection with the origin server to retrieve non-cacheable content. The domain name from the host-tag field is used to look up the origin
IP address on the CSA.Currently, you can use the bypass-hosttag command only with a CSS operating in a CSA environment. For details on CSA, refer to the Cisco Content Services Switch Global Server Load-Balancing Configuration Guide.
For example, enter:
(config-service[serv1])# bypass-hosttagTo disable bypassing cache for non-cacheable content, enter:
(config-service[serv1])# no bypass-hosttagConfiguring Maximum TCP Connections
By default, there is no limit on the number of TCP connections on a service. To define the maximum number of TCP connections on a service, use the max connections command. Enter the maximum number of connections from 6 to 65534. The default is 65534, which indicates that there is no limit on the number of connections.
Note
For example:
(config-service[serv1])# max connections 7To set the maximum TCP connections to the default value, enter:
(config-service[serv1])# no max connections
Note
Configuring Keepalives for a Service
The default service keepalive is ICMP with a frequency and retry period of 5 seconds, and a maximum failure rate of 3 times. For information on configuring keepalives for a service, see Chapter 4, Configuring Service, Global, and Script Keepalives.
Activating a Service
Once you configure a service, you must activate it to enable the CSS to access it for content requests. Activating a service puts it into the resource pool for load-balancing content requests and starts the keepalive function.
Note
The following command activates service serv1:
(config-service[serv1])# active
Note
For information on adding to a content rule, see Chapter 9, Configuring Content Rules. For information on adding a service to a source group, see Chapter 5, Configuring Source Groups for Services.
Suspending a Service
Suspending a service removes it from the pool for future load-balancing content requests. Suspending a service does not affect existing content flows, but it prevents additional connections from accessing the service for its content. You may want to suspend a service prior to performing maintenance on the service. The following command suspends service serv1:
(config-service[serv1])# suspend
Note
Showing Service Configurations
Before activating a service, you may want to display the service configuration to ensure that all the parameters are correct. The show service command enables you to display information for a specific service or all services currently configured in the CSS, depending on the location from where you issue the command.
You can issue the following show service commands from any mode:
•
•
•
From a specific service mode, the show service command displays configuration information only for that service. For example:
(config-service[serv1])# show serviceWhen you issue this command from any other mode, it displays configuration information for all services.
To display information for a specific service, use the show service command with the service name. For example:
# show service serv86The show service summary command displays a summary of all service currently configured.
Note
Table 3-2 describes the fields in the show service command output.
Table 3-2 Field Descriptions for the show service Command
OutputName
The name of the service.
Index
The CSS assigned unique numeric index.
Type
The type for the service. If you do not define a type for the service, the default service type is local. The possible types are:
•
•
•
•
•
•
•
•
•
•
State
The state of the service. The State field displays the service as Alive, Dying, Down, or Suspended. The Dying state reports that a service is failing according to the parameters configured in the following service mode commands: keepalive retryperiod, keepalive frequency, and keepalive maxfailure. When a service enters the Down state, the CSS does not forward any new connections to it (the service is removed from the load-balancing rotation for the content rule). However, the CSS keeps all existing connections to the service (that is, connections to that service are not "torn down").
Rule
The address, protocol, and port information for the service.
Redirect Domain
The domain name to be used when an HTTP redirect service generates an OBJECT MOVED message for the service.
Session Redundancy
Indicates whether Adaptive Session Redundancy (ASR) is enabled or disabled for the service. For details on ASR, refer to the Cisco Content Services Switch Global Server Load-Balancing Configuration Guide.
SSL-Accel Slot
The slot in the CSS where the SSL module is located. An SSL service requires the SSL module slot number in order to correlate the SSL proxy list to a specific SSL module. For details on SSL, refer to the Cisco Content Services Switch SSL Configuration Guide.
Session Cache Size
The size of the SSL session ID cache for the service. The cache size is the maximum number of SSL session IDs that can be stored in a dedicated session cache on an SSL module.
Redundancy Global Index
The unique global index value for ASR assigned to the service using the redundant-index command in service configuration mode.
Redirect String
The HTTP redirect string to be used when an HTTP redirect service generates an OBJECT MOVED message for the service.
Keepalive
The keepalive type, frequency, maxfailure, and retry period. The possible keepalive types are:
•
•
•
•
•
•
•
•
The keepalive frequency value is the interval in seconds between keepalive messages sent to the service. The default is 5. The range is from 2 to 255.
The keepalive maxfailure value is the number of times the service can fail to respond to a keepalive message before being considered down. The default is 3. The range is from 1 to 10.
The keepalive retry period value is the interval in seconds between retry messages sent to the service. The default is 5. The range is from 2 to 255.
Last Clearing of Stats Counters
The date and time when the State Transitions, Total Connections, or Total Reused Conns. counters were last cleared (reset to 0). The date and time stamp initially shown reflects when the service was activated or 01/01/00 00:00:00 if the service is down.
Mtu
The size of the largest datagram that can be sent or received on the service.
State Transitions
The total number of state transitions on the service. If the State Transitions field is 0, the 0 value can be due to a counter reset through either the global configuration mode zero service state-transitions command or the content mode zero state-transitions command. The counter can also be 0 if the service is down, or if the service is alive but no traffic is running.
Total Local Connections
Total number of TCP connections mastered by the CSS in an ASR configuration.
Current Local Connections
Number of current active TCP connections on the CSS in an ASR configuration.
Total Backup Connections
Total number of TCP connections backed up by the CSS for the master CSS in an ASR configuration.
Current Backup Connections
Number of curent TCP connections that the CSS is backing up in an ASR configuration.
Total Connections
The total number of connections that have been mapped to the service. In an Adaptive Session Redundancy configuration, Total Connections equals the sum of the Total Local Connections and the Total Backup Connections. If the Total Connections field is 0, the 0 value can be due to a counter reset through either the global configuration mode zero service total-connections command or the content mode zero total-connections command. The counter can also be 0 if the service is down, or if the service is alive but no traffic is running.
Max Connections
The configured maximum number of TCP connections on the service.
Total Reused Conns.
The total number of connections that were reused for multiple content requests during persistent connections. If the Total Reused Conns field is 0, the 0 value can be due to a counter reset through either the global configuration mode zero service total-reused-connections command or the content mode zero total-reused connections command. The counter can also be 0 if the service is down, or if the service is alive but no traffic is running.
Weight
The service weight used with load metrics to make load allocation decisions. The weight is used in ArrowPoint Content Awareness (ACA) and weighted roundrobin load balancing decisions. The range is from 1 to 10. The default is 1.
Load/Average Load
The current and average load for the service.
DFP
State of the Dynamic Feedback Protocol (DFP). Possible states are Enable or Disable. The DFP state is Disable if either DFP is not configured or DFP is configured and you have configured a weight on a service using the add service weight command in owner-content configuration mode. For details on DFP, see Chapter 7, Configuring Dynamic Feedback Protocol for Server Load Balancing.
Clearing Service Statistics Counters
To clear a specific service statistics counter for all existing CSS services and to set that counter to zero, use the zero service command. The reset statistics appear as 0 in the show service display. The zero service command is available in all modes.
Use the following zero service commands from any mode:
•
•
•
For example, to clear the Total Connections counter for all services, enter:
(config)# zero service total-connections
Note
Where to Go Next
For information on configuring keepalives, source groups, loads, and Dynamic Feedback Protocol (DFP), see the following chapters:
•
•
•
•
For information on creating and configuring owners, see Chapter 8, Configuring Owners.
