Configure layer 7 content switching

NetScaler Application Delivery Management (ADM) orchestrates with OpenStack to configure the Layer 7 (L7) switching or content-based switching functionalities on NetScaler instances. Content switching differs from simple load balancing in that specific types of requests can be directed to specific servers. When the L7 configurations are created in OpenStack with a NetScaler instance as the provider, NetScaler ADM allots a NetScaler instance, and deploys content switching and responder configurations corresponding to the L7 configurations. The NetScaler instances can then distribute and load balance user requests on the basis of application-layer characteristics of the requests.

The OpenStack layer 7 (L7) load balancing feature combines load balancing and content switching to provide optimized delivery of specific types of content. This improves the performance of the load balancer by running only those policies that are applicable to the content. Layer 7 load balancing also facilitates increased efficiency of the application infrastructure. The ability to separate out content according to type, URI, or data allows better allocation of physical resources in the application infrastructure. For example, an end user browsing to http://example-sports.com/about-us is served by a pool of servers hosting content about the company and the services, while a user browsing to http://example-sports.com/shopping-cart-football is served by a different pool of servers that allows the users to make online purchases.

In L7 switching, a load balancer is implemented as a content switching virtual server that accepts HTTP requests from users and distributes those requests to the application servers. L7 switching or content switching allows you to have a single-point entry to access a variety of the back-end services (for example, not just web applications, web service portals, web mails, but also mobile management, content in different languages, and so on). That is, you can provide one public IP address for all services you are offering your users.

Unlike lower-level load balancing, Layer 7 switching does not require that all servers in the pool have the same content. A load balancer configuration using L7 switching expects the application or back-end servers from different pools to have different content. L7 switches can direct requests on the basis of URI, host, HTTP headers, or anything else in the application message. The application servers are essentially serve specific types of content. For example, one server can serve only images, another might run server-side scripting languages, such as PHP and ASP, and another can serve static content such as HTML, CSS, and JavaScript.

L7 Rules

The following attributes are defined in a rule for evaluating the traffic and they are compared against the values defined in the rule:

• Host name: The host name in the HTTP request is compared against the value parameter in the rule. For example, “www.example-sports.com.”

• path: The path portion of the HTTP URI is compared against the value parameter in the rule. For example, “www.example-sports.com/shopping-cart/football_pump.html”

• file_type: The last portion of the URI is compared against the value parameter in the rule. For example, txt, html, jpg, PNG, xls, and others.

• header: The header defined in the key parameter is compared against the value parameter in the rule.

• cookie: The cookie named by the key parameter is compared against the value parameter in the rule. The cookie request-header field value contains a name and value pair of information stored for that URL; the general syntax is as follows - Cookie: name=value. For example, a rule that is looking for a cookie named “stores” with the value starting with “football-“ will look like: type = Cookie, compare_type=StartsWith, key = stores value = football-.

Comparison Types

When evaluating the traffic, the L7 policy compares the following expressions against the attributes defined in the rule.

• regex: Perl type regular expression matching

• starts_with: String start with

• ends_with: String ends with

• contains: String contains

• equal_to: String equals

Note

The host name, path, header, and cookie attributes support all comparison types, but the file_type attribute supports only regex and equal_to.

L7 Policies

An L7 policy processes the incoming HTTP traffic and returns a “true” value when all the rules defined in the policy are matched.

In any L7 policy, all the rules are logically joined with an AND operator. A request must match all the rules so that the policy returns a “true” value. The action taken by the load balancer is based on the value returned by the policy. You can create a second policy with the same action to achieve a logical OR operation between the rules.

For example, you can create one policy where the incoming HTTP request can contain the words “EXAMPLE-SPORTS,” “SPORTS-FOOTBALL,” or “EXAMPLE-FOOTBALL,” so that the load balancer takes the appropriate action of forwarding these requests to the server-pool of the Example-sports ecommerce company to serve the requested content. You can create another policy that takes the same action but matches “example-sports,” “example-sports-football,” or “ example-football.” When a user sends an HTTP request with any of these six keywords, the load balancer forwards the request to the Example-Sports server.

Depending on the rules defined in the policy, an L7 policy can take any of the following actions:

• Redirect to pool - Forward the request to the application server pool identified by the rules associated with the L7 policy. That is, you can create an application rule to direct requests to a specific load balancer pool according to domain name. For example, you can create a rule that directs some requests to example-football.com to pool_1, and other requests to example-sports-online_purchase.com to pool_2.

• Redirect to URL - Send the client a redirect HTTP response in which the location response header contains the new location. The browser will update the address bar with the new location and issue a new request. The use cases are many. For example, if a website address has changed, you can redirect requests to the new address instead of dropping. Or, during website maintenance, you can redirect the users to a read-only site.

• Reject - Rejects the request and takes no further action. For example, you can return a 401 Unauthorized response to deny access to the users for restricted webpages.

A content switching configuration consists of a content switching virtual server, a load balancing setup consisting of load balancing virtual servers and services, and content switching policies. After you create your content switching virtual server and policies, you bind each policy to the content switching virtual server. When binding the policy to the content switching virtual server, you specify the target load balancing virtual server. When a request reaches the content switching virtual server, the virtual server applies the associated content switching policies to that request. The priority of the policy defines the order in which the policies bound to the content switching virtual server are evaluated.

Any pool that has the listener ID can be assigned as a default pool of virtual servers to which traffic is diverted. The pool is loosely bound with a listener, and becomes associated with a listener only through implementation of an L7 policy.  A pool can also be created directly under a load balancer without necessarily being tied to a listener. In such a case, the pool is created in a “pending_create” state. Because the L7 policies are tightly bound with the listeners, an L7 policy containing the pool ID must be created and implemented for the pool to become “active” and start receiving traffic requests.

A pool can be served by multiple L7 policies, but remains in the “active” state if at least one policy is attached to it. When the last policy is removed, the pool goes back into the “pending_create” state until another policy is created and associated with it. If the pool itself is removed, all HTTP requests that it would otherwise have received are redirected to the default pool.

Mapping Between OpenStack L7 Policies and NetScaler Entities

If the action of an L7 policy that evaluates to “true” redirects traffic to a pool that is in “create_pending” state, NetScaler ADM implements the specified pool along with a load balancing virtual server. NetScaler ADM creates a content switching policy out of the L7 policy and uses the corresponding content switching action to redirect the requests to the load balancing virtual server associated with that pool. If a second L7 policy redirects to the same pool, NetScaler ADM creates a content switching policy and a content switching action to redirect the traffic to the existing load balancing virtual server associated with the pool.

Policy Positioning

Evaluation of L7 policies in OpenStack is determined by their priorities. In OpenStack, by default, the policies are assigned priorities in the order in which they are created. The policy created first is numbered “1,” and subsequently created policies are numbered consecutively. But you can change the priorities of the policies and assign them different priorities. The policies are always evaluated in the order of their priorities.  The first policy that matches a specific request is always ran first.

When creating policies, note the following points:

• If you assign a new policy the same priority as an existing policy, the new policy takes that priority. The existing policy’s priority is lowered. If necessary, the priorities of other policies are also lowered to retain the order in which the policies are evaluated.

• If you create a new policy without specifying a position, the new policy will just be appended to the list.

• If you create a new policy and assign it a position that is greater than the number of policies already in the list, the new policy will be appended to the list, that is, the new policy always takes the next available priority. For example, if there are three policies A, B, and C with priorities 1,2, and 3, and if you create a policy and assign a priority of 8, the new policy’s priority becomes 4.

• If you add a policy to the list or delete a policy from the list, the policy position values are re-ordered from 1 without skipping numbers. For example, if policy A, B, C, and D have position values of 1, 2, 3, and 4, and if you delete policy B from the list, policy C now takes the second position, and policy D takes the third position.

In NetScaler ADM, there is always a default policy associated with a csvserver with a priority of 1. This default policy specifies the number of TCP connections that an lbvserver processes at any given point of time. Therefore, when the corresponding responder policies and content switching policies are created in NetScaler, they are always assigned a priority 1 greater than the priority of the corresponding L7 policy. For example, when an L7 policy with a priority of 1 is evaluated and a content switching policy is created with a priority of 2. Similarly, when an L7 policy with a priority of 2 is evaluated and a responder policy is created with a priority of 3.

In OpenStack, the “reject” or “redirect_to_url” policy is first evaluated, and then the “redirect_to_pool policy is evaluated. In a NetScaler instance, the responder policies are always evaluated first to either drop the request or present the user with a redirected web address, and the content switching policies are evaluated last. This order of evaluation usually does not cause any conflict if the content switching and responder policies are mutually exclusive. That is, two L7 policies must not have identical expressions. The derived expressions are added in the responder and content switching policies to avoid such conflicts. For example, write an expression to reject all requests to “sports-football.com” and another expression to allow requests to “example-sports-football.com.” Create the L7 polices so that all the responder policies to reject the request are arranged at the top of the evaluation list, followed by the responder policies for web direct, followed by the content switching policies.

In NetScaler ADM, there is always a default policy associated with a csvserver with a priority of 1. This default policy specifies the number of TCP connections that an lbvserver processes at any given point of time.  Therefore, when the corresponding responder policies and content switching policies are created in NetScaler, they are always assigned a priority 1 greater than the priority of the corresponding L7 policy. For example, when an L7 policy with a priority of 1 is evaluated and a content switching policy is created with a priority of 2. Similarly, when an L7 policy with a priority of 2 is evaluated and a responder policy is created with a priority of 3.

In OpenStack, the “reject” or “redirect_to_url” policy is first evaluated and then the “redirect_to_pool policy is evaluated. In NetScaler, the responder policies are always evaluated first to either drop the request or present the user with a redirected web address, and the content switching policies are evaluated last. This order of evaluation usually does not cause any conflict if the content switching and responder policies are mutually exclusive. That is, no two L7 policies have similar expressions. Similar derived expressions are added in the responder and content switching policies to avoid such conflicts. For example, write an expression to reject all requests to “sports-football.com” and another expression to allow requests to “example-sports-football.com.” Create the L7 polices so that all the responder policies to reject the request are arranged at the top of the evaluation list, followed by the responder policies for web direct, followed by the content switching policies.

Configuration Tasks

The L7 policy and action implementations are performed through Neutron LBaaS commands.

Set the environment variables in OpenStack and create the load balancer (for example, LB1). After the load balancer is successfully created, create the listener and pools (for example, L1, P1, and P2), and add members and monitors to the pools. For example, P1 is the default pool for L1, while P2 is the pool tied to LB1 and managing the application servers.

For more information on how to configure LBaaS V2 by using the command line, see Configuring LBaaS V2 using Command Line.

The following commands create the policies and define the specific actions:

Create L7 Policy to Drop Requests

neutron lbaas-l7policy-create --name <L7 policy name> --listener <listener name> --action<action-name>

Example:

neutron lbaas-l7policy-create –name policy11 –action REJECT –listener L1

The above command creates and binds policy11, a responder policy, to the content switching server to reject requests. Because no rule was created for this policy, the policy evaluates to “false” and the request is rejected.

Create L7 Policy to Redirect Requests to Particular URL

neutron lbaas-l7policy-create --name <L7 policy name> --listener <listener name> --action <action-name> --redirect-url <redirect-url>

Example:

neutron lbaas-l7policy-create –name policy12 –action REDIRECT_TO_URL –listener admin-list1 –redirect-url http://example-sports/about-us.html

The above command creates a responder action to redirect requests to a URL, creates a responder policy with action, and binds this policy to the content switching virtual server.

neutron lbaas-l7rule-create --type HOST_NAME --compare-type CONTAINS --value <value-string> <L7 policy name>

neutron lbaas-l7rule-create --type PATH --compare-type CONTAINS --value <value-string> <L7 policy name>

The above two rules can be connected with an AND operator to derive the expression for the responder policy.

Create L7 Policy to Redirect Requests to a Pool

neutron lbaas-l7policy-create --name <L7 policy name> --listener <listener name> --action <action-name> --redirect-pool <redirect-pool>

Example:

neutron lbaas-l7policy-create –name policy13 –action REDIRECT_TO_POOL –listener admin-list1 –redirect-pool admin-pool2

If this is the first L7 policy, the above command implements P2 along with LB1, creates the content switching redirect action and redirects the requests to LB1. If P2 already exists, the command creates the content switching redirect action and redirects the requests to LB1.