Chapter 10. Implementing layer 7 load balancing

You can use the Red Hat OpenStack Platform Load-balancing service (octavia) with layer 7 policies to redirect HTTP requests to particular application server pools by using several criteria to meet your business needs.

10.1. About layer 7 load balancing

Layer 7 (L7) load balancing takes its name from the Open Systems Interconnection (OSI) model, indicating that the load balancer distributes requests to back end application server pools based on layer 7 (application) data. The following are different terms that all mean L7 load balancing: request switching, application load balancing, and content-based- routing, switching, or balancing. The Red Hat OpenStack Platform Load-balancing service (octavia) provides robust support for L7 load balancing.

Note

You cannot create L7 policies and rules with UDP load balancers.

An L7 load balancer consists of a listener that accepts requests on behalf of a number of back end pools and distributes those requests based on policies that use application data to determine which pools service any given request. This allows for the application infrastructure to be specifically tuned and optimized to serve specific types of content. For example, you can tune one group of back end servers (a pool) to serve only images; another for execution of server-side scripting languages like PHP and ASP; and another for static content such as HTML, CSS, and JavaScript.

Unlike lower-level load balancing, L7 load balancing does not require that all pools behind the load balancing service have the same content. L7 load balancers can direct requests based on URI, host, HTTP headers, and other data in the application message.

10.2. Layer 7 load balancing in the Load-balancing service

Although you can implement layer 7 (L7) load balancing for any well-defined L7 application interface, L7 functionality for the Red Hat OpenStack Platform Load-balancing service (octavia) refers only to the HTTP and TERMINATED_HTTPS protocols and its semantics.

Neutron LBaaS and the Load-balancing service use L7 rules and policies for the logic of L7 load balancing. An L7 rule is a single, simple logical test that evaluates to true or false. An L7 policy is a collection of L7 rules and a defined action to take if all the rules associated with the policy match.

10.3. Layer 7 load-balancing rules

For the Red Hat OpenStack Platform Load-balancing service (octavia), a layer 7 (L7) load-balancing rule is a single, simple logical test that returns either true or false. It consists of a rule type, a comparison type, a value, and an optional key that is used depending on the rule type. An L7 rule must always be associated with an L7 policy.

Note

You cannot create L7 policies and rules with UDP load balancers.

Additional resources

10.4. Layer 7 load-balancing rule types

The Red Hat OpenStack Platform Load-balancing service (octavia) has the following types of layer 7 load-balancing rules:

  • HOST_NAME: The rule compares the HTTP/1.1 hostname in the request against the value parameter in the rule.
  • PATH: The rule compares the path portion of the HTTP URI against the value parameter in the rule.
  • FILE_TYPE: The rule compares the last portion of the URI against the value parameter in the rule, for example, txt, jpg, and so on.
  • HEADER: The rule looks for a header defined in the key parameter and compares it against the value parameter in the rule.
  • COOKIE: The rule looks for a cookie named by the key parameter and compares it against the value parameter in the rule.
  • SSL_CONN_HAS_CERT: The rule matches if the client has presented a certificate for TLS client authentication. This does not imply that the certificate is valid.
  • SSL_VERIFY_RESULT: This rule matches the TLS client authentication certificate validation result. A value of zero (0) means the certificate was successfully validated. A value greater than zero means the certificate failed validation. This value follows the openssl-verify result codes.
  • SSL_DN_FIELD: The rule looks for a Distinguished Name field defined in the key parameter and compares it against the value parameter in the rule.

Additional resources

10.5. Layer 7 load-balancing rule comparison types

For the Red Hat OpenStack Platform Load-balancing service (octavia), layer 7 load-balancing rules of a given type always perform comparisons. The Load-balancing service supports the following types of comparisons. Not all rule types support all comparison types:

  • REGEX: Perl type regular expression matching
  • STARTS_WITH: String starts with
  • ENDS_WITH: String ends with
  • CONTAINS: String contains
  • EQUAL_TO: String is equal to

Additional resources

10.6. Layer 7 load-balancing rule result inversion

To more fully express the logic that some policies require and the Red Hat OpenStack Platform Load-balancing service (octavia) uses, layer 7 load-balancing rules can have their result inverted. If the invert parameter of a given rule is true, the result of its comparison is inverted.

For example, an inverted equal to rule effectively becomes a not equal to rule. An inverted regex rule returns true only if the given regular expression does not match.

Additional resources

10.7. Layer 7 load-balancing policies

For the Red Hat OpenStack Platform Load-balancing service (octavia), a layer 7 (L7) load-balancing policy is a collection of L7 rules associated with a listener, and which might also have an association to a back end pool. Policies are actions that the load balancer takes if all of the rules in the policy are true.

Note

You cannot create L7 policies and rules with UDP load balancers.

Additional resources

10.8. Layer 7 load-balancing policy logic

The Red Hat OpenStack Platform Load-balancing service (octavia), layer 7 load-balancing policy uses the following logic: all the rules associated with a given policy are logically AND-ed together. A request must match all of the policy rules to match the policy.

If you need to express a logical OR operation between rules, create multiple policies with the same action or, make a more elaborate regular expression).

Additional resources

10.9. Layer 7 load-balancing policy actions

If the layer 7 load-balancing policy matches a given request, then that policy action is executed. The following are the actions an L7 policy might take:

  • REJECT: The request is denied with an appropriate response code, and not forwarded on to any back end pool.
  • REDIRECT_TO_URL: The request is sent an HTTP redirect to the URL defined in the redirect_url parameter.
  • REDIRECT_PREFIX: Requests matching this policy are redirected to this prefix URL.
  • REDIRECT_TO_POOL: The request is forwarded to the back-end pool associated with the L7 policy.

Additional resources

10.10. Layer 7 load-balancing policy position

For the Red Hat OpenStack Platform (RHOSP) Load-balancing service (octavia), when multiple layer 7 (L7) load-balancing policies are associated with a listener, then the value of the policy position parameter becomes important. The position parameter is used when determining the order that L7 policies are evaluated. The policy position affects listener behavior in the following ways:

  • In the reference implementation of the Load-balancing service (haproxy amphorae), HAProxy enforces the following ordering regarding policy actions:

    • REJECT policies take precedence over all other policies.
    • REDIRECT_TO_URL policies take precedence over REDIRECT_TO_POOL policies.
    • REDIRECT_TO_POOL policies are evaluated only after all of the above, and in the order that the position of the policy specifies.
  • L7 policies are evaluated in a specific order, as defined by the position attribute, and the first policy that matches a given request is the one whose action is followed.
  • If no policy matches a given request, then the request is routed to the listener’s default pool, if it exists. If the listener has no default pool, then an error 503 is returned.
  • Policy position numbering starts with one (1).
  • If a new policy is created with a position that matches that of an existing policy, then the new policy is inserted at the given position.
  • If a new policy is created without specifying a position, or specifying a position that is greater than the number of policies already in the list, the new policy is appended to the list.
  • When policies are inserted, deleted, or appended to the list, the policy position values are re-ordered from one (1) without skipping numbers. For example, if policy A, B, and C have position values of 1, 2 and 3 respectively, if you delete policy B from the list, the position for policy C becomes 2.

Additional resources

10.11. Redirecting unsecure HTTP requests to secure HTTP

You can use the Red Hat OpenStack Platform (RHOSP) Load-balancing service (octavia) with layer 7 (L7) policies to redirect HTTP requests that are received on a non-secure TCP port to a secure TCP port.

In this example, any HTTP requests that arrive on the unsecure TCP port, 80, are redirected to the secure TCP port, 443.

Prerequisites

Procedure

  1. Source your credentials file.

    Example

    $ source ~/overcloudrc

  2. Create an HTTP listener (http_listener) on a load balancer (lb1) port (80).

    Note

    Values inside parentheses are sample values that are used in the example commands in this procedure. Substitute these sample values with ones that are appropriate for your site.

    Example

    $ openstack loadbalancer listener create --name http_listener --protocol HTTP --protocol-port 80 lb1

  3. Create an L7 policy (policy1) on the listener (http_listener). The policy must contain the action (REDIRECT_TO_URL) and point to the URL (https://www.example.com/).

    Example

    $ openstack loadbalancer l7policy create --action REDIRECT_PREFIX --redirect-prefix https://www.example.com/ --name policy1 http_listener

  4. Add an L7 rule that matches all requests to a policy (policy1).

    Example

    $ openstack loadbalancer l7rule create --compare-type STARTS_WITH --type PATH --value / policy1

Verification

  1. Run the openstack loadbalancer l7policy list command and verify that the policy, policy1, exists.

  2. Run the openstack loadbalancer l7rule list <l7policy> command and verify that a rule with a compare_type of STARTS_WITH exists.

    Example

    $ openstack loadbalancer l7rule list policy1

Additional resources

10.12. Redirecting requests based on the starting path to a pool

You can use the Red Hat OpenStack Platform (RHOSP) Load-balancing service (octavia) to redirect HTTP requests to an alternate pool of servers. You can define a layer 7 (L7) policy to match one or more starting paths in the URL of the request.

In this example, any requests that contain URLs that begin with /js or /images are redirected to an alternate pool of static content servers.

Prerequisites

Procedure

  1. Source your credentials file.

    Example

    $ source ~/overcloudrc

  2. Create a second pool (static_pool) on a load balancer (lb1).

    Note

    Values inside parentheses are sample values that are used in the example commands in this procedure. Substitute these sample values with ones that are appropriate for your site.

    Example

    $ openstack loadbalancer pool create --lb-algorithm ROUND_ROBIN --loadbalancer lb1 --name static_pool --protocol HTTP

  3. Add load balancer members (192.0.2.10 and 192.0.2.11) on the private subnet (private_subnet) to the pool (static_pool):

    Example

    $ openstack loadbalancer member create --subnet-id private_subnet --address 192.0.2.10 --protocol-port 80 static_pool
$ openstack loadbalancer member create --subnet-id private_subnet --address 192.0.2.11 --protocol-port 80 static_pool

  4. Create an L7 policy (policy1) on the listener (listener1). The policy must contain the action (REDIRECT_TO_POOL) and point to the pool (static_pool).

    Example

    $ openstack loadbalancer l7policy create --action REDIRECT_TO_POOL --redirect-pool static_pool --name policy1 listener1

  5. Add an L7 rule that looks for /js at the start of the request path to the policy.

    Example

    $ openstack loadbalancer l7rule create --compare-type STARTS_WITH --type PATH --value /js policy1

  6. Create an L7 policy (policy2) with an action (REDIRECT_TO_POOL) and add the listener (listener1) pointed at the pool.

    Example

    $ openstack loadbalancer l7policy create --action REDIRECT_TO_POOL --redirect-pool static_pool --name policy2 listener1

  7. Add an L7 rule that looks for /images at the start of the request path to the policy.

    Example

    $ openstack loadbalancer l7rule create --compare-type STARTS_WITH --type PATH --value /images policy2

Verification

  1. Run the openstack loadbalancer l7policy list command and verify that the policies, policy1 and policy2, exist.

  2. Run the openstack loadbalancer l7rule list <l7policy> command and verify that a rule with a compare_type of STARTS_WITH exists for each respective policy.

    Example

    $ openstack loadbalancer l7rule list policy1
$ openstack loadbalancer l7rule list policy2

Additional resources

10.13. Sending subdomain requests to a specific pool

You can use the Red Hat OpenStack Platform (RHOSP) Load-balancing service (octavia) with layer 7 (L7) policies to redirect requests containing a specific HTTP/1.1 hostname to a different pool of application servers.

In this example, any requests that contain the HTTP/1.1 hostname, www2.example.com, are redirected to an alternate pool application servers, pool2.

Prerequisites

Procedure

  1. Source your credentials file.

    Example

    $ source ~/overcloudrc

  2. Create a second pool (pool2) on the load balancer (lb1).

    Note

    Values inside parentheses are sample values that are used in the example commands in this procedure. Substitute these sample values with ones that are appropriate for your site.

    Example

    $ openstack loadbalancer pool create --lb-algorithm ROUND_ROBIN --loadbalancer lb1 --name pool2 --protocol HTTP

  3. Create an L7 policy (policy1) on the listener (listener1). The policy must contain the action (REDIRECT_TO_POOL) and point to the pool (pool2).

    Example

    $ openstack loadbalancer l7policy create --action REDIRECT_TO_POOL --redirect-pool pool2 --name policy1 listener1

  4. Add an L7 rule to the policy that sends any requests using the HTTP/1.1 hostname, www2.example.com, to the second pool (pool2).

    Example

    $ openstack loadbalancer l7rule create --compare-type EQUAL_TO --type HOST_NAME --value www2.example.com policy1

Verification

  1. Run the openstack loadbalancer l7policy list command and verify that the policy, policy1, exists.

  2. Run the openstack loadbalancer l7rule list <l7policy> command and verify that a rule with a compare_type of EQUAL_TO exists for the policy.

    Example

    $ openstack loadbalancer l7rule list policy1

Additional resources

10.14. Sending requests based on the host name ending to a specific pool

You can use the Red Hat OpenStack Platform (RHOSP) Load-balancing service (octavia) with layer 7 (L7) policies to redirect requests containing an HTTP/1.1 hostname that ends in a specific string to a different pool of application servers.

In this example, any requests that contain an HTTP/1.1 hostname that ends with, .example.com, are redirected to an alternate pool application server, pool2.

Prerequisites

Procedure

  1. Source your credentials file.

    Example

    $ source ~/overcloudrc

  2. Create a second pool (pool2) on the load balancer (lb1).

    Note

    Values inside parentheses are sample values that are used in the example commands in this procedure. Substitute these sample values with ones that are appropriate for your site.

    Example

    $ openstack loadbalancer pool create --lb-algorithm ROUND_ROBIN --loadbalancer lb1 --name pool2 --protocol HTTP

  3. Create an L7 policy (policy1) on the listener (listener1). The policy must contain the action (REDIRECT_TO_POOL) and point to the pool (pool2).

    Example

    $ openstack loadbalancer l7policy create --action REDIRECT_TO_POOL --redirect-pool pool2 --name policy1 listener1

  4. Add an L7 rule to the policy that sends any requests that use an HTTP/1.1 hostname (www2.example.com) to the second pool (pool2).

    Example

    $ openstack loadbalancer l7rule create --compare-type ENDS_WITH --type HOST_NAME --value .example.com policy1

Verification

  1. Run the openstack loadbalancer l7policy list command and verify that the policy, policy1, exists.

  2. Run the openstack loadbalancer l7rule list <l7policy> command and verify that a rule with a compare_type of EQUAL_TO exists for the policy.

    Example

    $ openstack loadbalancer l7rule list policy1

Additional resources

10.17. Sending requests to a pool whose name matches the hostname and path

You can use the Red Hat OpenStack Platform (RHOSP) Load-balancing service (octavia) to redirect web client requests that match certain criteria to an alternate pool of application servers. The business logic criteria is performed through a layer 7 (L7) policy that attempts to match a predefined hostname and request path.

In this example, any web client requests that either match the hostname api.example.com, and have /api at the start of the request path are redirected to an alternate pool, api_pool.

Prerequisites

Procedure

  1. Source your credentials file.

    Example

    $ source ~/overcloudrc

  2. Create a second pool (api_pool) on the load balancer (lb1).

    Note

    Values inside parentheses are sample values that are used in the example commands in this procedure. Substitute these sample values with ones that are appropriate for your site.

    Example

    $ openstack loadbalancer pool create --lb-algorithm ROUND_ROBIN --loadbalancer lb1 --name api_pool --protocol HTTP

  3. Add load balancer members (192.0.2.10 and 192.0.2.11) on the private subnet (private_subnet) to the pool (static_pool):

    Example

    $ openstack loadbalancer member create --subnet-id private_subnet --address 192.0.2.10 --protocol-port 80 static_pool
$ openstack loadbalancer member create --subnet-id private_subnet --address 192.0.2.11 --protocol-port 80 static_pool

  4. Create an L7 policy (policy1) on the listener (listener1). The policy must contain the action (REDIRECT_TO_POOL) and point to the pool (api_pool).

    Example

    $ openstack loadbalancer l7policy create --action REDIRECT_TO_POOL --redirect-pool api_pool --name policy1 listener1

  5. Add an L7 rule to the policy that matches the hostname api.example.com.

    Example

    $ openstack loadbalancer l7rule create --compare-type EQUAL_TO --type HOST_NAME --value api.example.com policy1

  6. Add a second L7 rule to the policy that matches /api at the start of the request path.

    This rule is logically ANDed with the first rule.

    Example

    $ openstack loadbalancer l7rule create --compare-type STARTS_WITH --type PATH --value /api policy1

Verification

  1. Run the openstack loadbalancer l7policy list command and verify that the policy, policy1, exists.

  2. Run the openstack loadbalancer l7rule list <l7policy> command and verify that rules with a compare_type of EQUAL_TO and STARTS_WITH, respectively, both exist for policy1.

    Example

    $ openstack loadbalancer l7rule list policy1
$ openstack loadbalancer l7rule list policy2

Additional resources