Chapter 11. 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.
- Section 11.1, “About layer 7 load balancing”
- Section 11.2, “Layer 7 load balancing in the Load-balancing service”
- Section 11.3, “Layer 7 load-balancing rules”
- Section 11.4, “Layer 7 load-balancing rule types”
- Section 11.5, “Layer 7 load-balancing rule comparison types”
- Section 11.6, “Layer 7 load-balancing rule result inversion”
- Section 11.7, “Layer 7 load-balancing policies”
- Section 11.8, “Layer 7 load-balancing policy logic”
- Section 11.9, “Layer 7 load-balancing policy actions”
- Section 11.10, “Layer 7 load-balancing policy position”
- Section 11.11, “Redirecting unsecure HTTP requests to secure HTTP”
- Section 11.12, “Redirecting requests based on the starting path to a pool”
- Section 11.13, “Sending subdomain requests to a specific pool”
- Section 11.14, “Sending requests based on the host name ending to a specific pool”
- Section 11.15, “Sending requests based on absence of a browser cookie to a specific pool”
- Section 11.16, “Sending requests based on absence of a browser cookie or invalid cookie value to a specific pool”
- Section 11.17, “Sending requests to a pool whose name matches the hostname and path”
- Section 11.18, “Configuring A-B testing on an existing production site by using a cookie”
11.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.
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.
11.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.
11.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.
You cannot create L7 policies and rules with UDP load balancers.
Additional resources
11.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 theopenssl-verify
result codes. -
SSL_DN_FIELD
: The rule looks for aDistinguished Name
field defined in the key parameter and compares it against the value parameter in the rule.
Additional resources
11.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
11.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
11.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.
You cannot create L7 policies and rules with UDP load balancers.
Additional resources
11.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
11.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
11.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 of1
,2
and3
respectively, if you delete policy B from the list, the position for policy C becomes2
.
Additional resources
11.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
A TLS-terminated HTTPS load balancer (
lb1
) that has a listener (listener1
) and a pool (pool1
).For more information, see Creating a TLS-terminated HTTPS load balancer.
Procedure
Source your credentials file.
Example
$ source ~/overcloudrc
Create an HTTP listener (
http_listener
) on a load balancer (lb1
) port (80
).NoteValues inside parentheses are sample values that are used in the example commands in this procedure. Substitute these sample values with values that are appropriate for your site.
Example
$ openstack loadbalancer listener create --name http_listener \ --protocol HTTP --protocol-port 80 lb1
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 --name policy1 \ --action REDIRECT_PREFIX --redirect-prefix https://www.example.com/ \ http_listener
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
-
Run the
openstack loadbalancer l7policy list
command and verify that the policy,policy1
, exists. Run the
openstack loadbalancer l7rule list <l7policy>
command and verify that a rule with acompare_type
ofSTARTS_WITH
exists.Example
$ openstack loadbalancer l7rule list policy1
Additional resources
- loadbalancer listener create in the Command Line Interface Reference
- loadbalancer l7policy create in the Command Line Interface Reference
- loadbalancer l7rule create in the Command Line Interface Reference
11.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
An HTTP load balancer (
lb1
) that has a listener (listener1
) and a pool (pool1
).For more information, see Creating an HTTP load balancer with a health monitor.
Procedure
Source your credentials file.
Example
$ source ~/overcloudrc
Create a second pool (
static_pool
) on a load balancer (lb1
).NoteValues inside parentheses are sample values that are used in the example commands in this procedure. Substitute these sample values with values that are appropriate for your site.
Example
$ openstack loadbalancer pool create --name static_pool \ --lb-algorithm ROUND_ROBIN --loadbalancer lb1 --protocol HTTP
Add load balancer members (
192.0.2.10
and192.0.2.11
) on the private subnet (private_subnet
) to the pool (static_pool
):Example
In this example, the back-end servers,
192.0.2.10
and192.0.2.11
, are namedmember1
andmember2
, respectively:$ openstack loadbalancer member create --name member1 --subnet-id \ private_subnet --address 192.0.2.10 --protocol-port 80 static_pool $ openstack loadbalancer member create --name member2 --subnet-id \ private_subnet --address 192.0.2.11 --protocol-port 80 static_pool
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 --name policy1 \ --action REDIRECT_TO_POOL --redirect-pool static_pool listener1
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
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 --name policy2 \ --action REDIRECT_TO_POOL --redirect-pool static_pool listener1
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
-
Run the
openstack loadbalancer l7policy list
command and verify that the policies,policy1
andpolicy2
, exist. Run the
openstack loadbalancer l7rule list <l7policy>
command and verify that a rule with acompare_type
ofSTARTS_WITH
exists for each respective policy.Example
$ openstack loadbalancer l7rule list policy1 $ openstack loadbalancer l7rule list policy2
Additional resources
- loadbalancer pool create in the Command Line Interface Reference
- loadbalancer member create in the Command Line Interface Reference
- loadbalancer l7policy create in the Command Line Interface Reference
- loadbalancer l7rule create in the Command Line Interface Reference
11.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
An HTTP load balancer (
lb1
) that has a listener (listener1
) and a pool (pool1
).For more information, see Creating an HTTP load balancer with a health monitor.
Procedure
Source your credentials file.
Example
$ source ~/overcloudrc
Create a second pool (
pool2
) on the load balancer (lb1
).NoteValues inside parentheses are sample values that are used in the example commands in this procedure. Substitute these sample values with values that are appropriate for your site.
Example
$ openstack loadbalancer pool create --name pool2 \ --lb-algorithm ROUND_ROBIN --loadbalancer lb1 --protocol HTTP
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 --name policy1 \ --action REDIRECT_TO_POOL --redirect-pool pool2 listener1
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
-
Run the
openstack loadbalancer l7policy list
command and verify that the policy,policy1
, exists. Run the
openstack loadbalancer l7rule list <l7policy>
command and verify that a rule with acompare_type
ofEQUAL_TO
exists for the policy.Example
$ openstack loadbalancer l7rule list policy1
Additional resources
- loadbalancer pool create in the Command Line Interface Reference
- loadbalancer l7policy create in the Command Line Interface Reference
- loadbalancer l7rule create in the Command Line Interface Reference
11.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
An HTTP load balancer (
lb1
) that has a listener (listener1
) and a pool (pool1
).For more information, see Creating an HTTP load balancer with a health monitor
Procedure
Source your credentials file.
Example
$ source ~/overcloudrc
Create a second pool (
pool2
) on the load balancer (lb1
).NoteValues inside parentheses are sample values that are used in the example commands in this procedure. Substitute these sample values with values that are appropriate for your site.
Example
$ openstack loadbalancer pool create --name pool2 \ --lb-algorithm ROUND_ROBIN --loadbalancer lb1 --protocol HTTP
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 --name policy1 \ --action REDIRECT_TO_POOL --redirect-pool pool2 listener1
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
-
Run the
openstack loadbalancer l7policy list
command and verify that the policy,policy1
, exists. Run the
openstack loadbalancer l7rule list <l7policy>
command and verify that a rule with acompare_type
ofEQUAL_TO
exists for the policy.Example
$ openstack loadbalancer l7rule list policy1
Additional resources
- loadbalancer pool create in the Command Line Interface Reference
- loadbalancer l7policy create in the Command Line Interface Reference
- loadbalancer l7rule create in the Command Line Interface Reference
11.15. Sending requests based on absence of a browser cookie to a specific pool
You can use the Red Hat OpenStack Platform (RHOSP) Load-balancing service (octavia) to redirect unauthenticated web client requests to a different pool that contains one or more authentication servers. A layer 7 (L7) policy determines whether the incoming request is missing an authentication cookie.
In this example, any web client requests that lack the browser cookie, auth_token
, are redirected to an alternate pool that contains an authentication server.
This procedure provides an example for how to perform L7 application routing by using a browser cookie, and does not address security concerns.
Prerequisites
A TLS-terminated HTTPS load balancer (
lb1
) that has a listener (listener1
) and a pool (pool1
).For more information, see Creating a TLS-terminated HTTPS load balancer
- A second RHOSP Networking service (neutron) subnet on which a secure authentication server authenticates web users.
Procedure
Source your credentials file.
Example
$ source ~/overcloudrc
Create a second pool (
login_pool
) on the load balancer (lb1
).NoteValues inside parentheses are sample values that are used in the example commands in this procedure. Substitute these sample values with values that are appropriate for your site.
Example
$ openstack loadbalancer pool create --name login_pool \ --lb-algorithm ROUND_ROBIN --loadbalancer lb1 --protocol HTTP
Add a member, the secure authentication server (
192.0.2.10
) on the authenticating subnet (secure_subnet
), to the second pool.Example
In this example, the back-end server,
192.0.2.10
, is namedmember1
:$ openstack loadbalancer member create --name member1 \ --address 192.0.2.10 --protocol-port 80 --subnet-id secure_subnet \ login_pool
Create an L7 policy (
policy1
) on the listener (listener1
). The policy must contain the action (REDIRECT_TO_POOL
) and point to the second pool (login_pool
).Example
$ openstack loadbalancer l7policy create --name policy1 \ --action REDIRECT_TO_POOL --redirect-pool login_pool listener1
Add an L7 rule to the policy (
policy1
) that searches for the browser cookie (auth_token
) with any value, and matches if the cookie is NOT present.Example
$ openstack loadbalancer l7rule create --compare-type REGEX \ --key auth_token --type COOKIE --value '.*' --invert policy1
Verification
-
Run the
openstack loadbalancer l7policy list
command and verify that the policy,policy1
, exists. Run the
openstack loadbalancer l7rule list <l7policy>
command and verify that a rule with acompare_type
ofREGEX
exists.Example
$ openstack loadbalancer l7rule list policy1
Additional resources
- loadbalancer pool create in the Command Line Interface Reference
- loadbalancer member create in the Command Line Interface Reference
- loadbalancer l7policy create in the Command Line Interface Reference
- loadbalancer l7rule create in the Command Line Interface Reference
11.16. Sending requests based on absence of a browser cookie or invalid cookie value to a specific pool
You can use the Red Hat OpenStack Platform (RHOSP) Load-balancing service (octavia) to redirect unauthenticated web client requests to a different pool that contains one or more authentication servers. A layer 7 (L7) policy determines whether the incoming request is missing an authentication cookie or contains an authentication cookie with a particular value.
In this example, any web client requests that either lacks the browser cookie, auth_token
, or has auth_token
with a value of INVALID
, are redirected to an alternate pool that contains an authentication server.
This procedure provides an example for how to perform L7 application routing using a browser cookie, and does not address security concerns.
Prerequisites
A TLS-terminated HTTPS load balancer (
lb1
) that has a listener (listener1
) and a pool (pool1
).For more information, see Creating a TLS-terminated HTTPS load balancer.
- A second RHOSP Networking service (neutron) subnet on which a secure authentication server authenticates web users.
Procedure
Source your credentials file.
Example
$ source ~/overcloudrc
Create a second pool (
login_pool
) on the load balancer (lb1
).NoteValues inside parentheses are sample values that are used in the example commands in this procedure. Substitute these sample values with values that are appropriate for your site.
Example
$ openstack loadbalancer pool create --name login_pool \ --lb-algorithm ROUND_ROBIN --loadbalancer lb1 --protocol HTTP
Add a member, the secure authentication server (
192.0.2.10
) on the authenticating subnet (secure_subnet
), to the second pool.Example
In this example, the back-end server,
192.0.2.10
, is namedmember1
:$ openstack loadbalancer member create --name member1 \ --address 192.0.2.10 --protocol-port 80 --subnet-id secure_subnet \ login_pool
Create an L7 policy (
policy1
) on the listener (listener1
). The policy must contain the action (REDIRECT_TO_POOL
) and point to the second pool (login_pool
).Example
$ openstack loadbalancer l7policy create --action REDIRECT_TO_POOL \ --redirect-pool login_pool --name policy1 listener1
Add an L7 rule to the policy (
policy1
) that searches for the browser cookie (auth_token
) with any value, and matches if the cookie is NOT present.Example
$ openstack loadbalancer l7rule create --compare-type REGEX \ --key auth_token --type COOKIE --value '.*' --invert policy1
Create a second L7 policy (
policy2
) on the listener (listener1
). The policy must contain the action (REDIRECT_TO_POOL
) and point to the second pool (login_pool
).Example
$ openstack loadbalancer l7policy create --action REDIRECT_TO_POOL \ --redirect-pool login_pool --name policy2 listener1
Add an L7 rule to the second policy (
policy2
) that searches for the browser cookie (auth_token
) and matches if the cookie value equals the stringINVALID
.Example
$ openstack loadbalancer l7rule create --compare-type EQUAL_TO \ --key auth_token --type COOKIE --value INVALID policy2
Verification
-
Run the
openstack loadbalancer l7policy list
command and verify that the policies,policy1
andpolicy2
, exist. Run the
openstack loadbalancer l7rule list <l7policy>
command and verify that a rule with acompare_type
ofREGEX
exists forpolicy1
and a rule with acompare_type
ofEQUAL_TO
exists forpolicy2
.Example
$ openstack loadbalancer l7rule list policy1 $ openstack loadbalancer l7rule list policy2
Additional resources
- loadbalancer pool create in the Command Line Interface Reference
- loadbalancer member create in the Command Line Interface Reference
- loadbalancer l7policy create in the Command Line Interface Reference
- loadbalancer l7rule create in the Command Line Interface Reference
11.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
An HTTP load balancer (
lb1
) that has a listener (listener1
) and a pool (pool1
).For more information, see Creating an HTTP load balancer with a health monitor.
Procedure
Source your credentials file.
Example
$ source ~/overcloudrc
Create a second pool (
api_pool
) on the load balancer (lb1
).NoteValues inside parentheses are sample values that are used in the example commands in this procedure. Substitute these sample values with values that are appropriate for your site.
Example
$ openstack loadbalancer pool create --name api_pool \ --lb-algorithm ROUND_ROBIN --loadbalancer lb1 --protocol HTTP
Add load balancer members (
192.0.2.10
and192.0.2.11
) on the private subnet (private_subnet
) to the pool (static_pool
):Example
In this example, the back-end servers,
192.0.2.10
and192.0.2.11
, are namedmember1
andmember2
, respectively:$ openstack loadbalancer member create --name member1 --subnet-id \ private_subnet --address 192.0.2.10 --protocol-port 80 static_pool $ openstack loadbalancer member create --name member2 --subnet-id \ private_subnet --address 192.0.2.11 --protocol-port 80 static_pool
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
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
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
-
Run the
openstack loadbalancer l7policy list
command and verify that the policy,policy1
, exists. Run the
openstack loadbalancer l7rule list <l7policy>
command and verify that rules with acompare_type
ofEQUAL_TO
andSTARTS_WITH
, respectively, both exist forpolicy1
.Example
$ openstack loadbalancer l7rule list policy1 $ openstack loadbalancer l7rule list policy2
Additional resources
- loadbalancer pool create in the Command Line Interface Reference
- loadbalancer member create in the Command Line Interface Reference
- loadbalancer l7policy create in the Command Line Interface Reference
- loadbalancer l7rule create in the Command Line Interface Reference
11.18. Configuring A-B testing on an existing production site by using a cookie
You can use the Red Hat OpenStack Platform (RHOSP) Load-balancing service (octavia) with layer 7 (L7) policies to configure A-B testing, or split testing, for your production websites.
In this example, web clients that are routed to the “B” version of the website set the cookie site_version
to B
by the member servers in the pool (pool1
).
Prerequisites
- Two production websites (site A and site B).
You have configured an HTTP load balancer following the instructions for "Redirecting requests based on the starting path to a pool." A summary of the required configuration is:
-
Listener (
listener1
) on load balancer (lb1
). -
HTTP requests with a URL that starts with either
/js
or/images
are sent to a pool (static_pool
). -
All other requests are sent to the listener default pool (
pool1
). - For more information about the configuration, see Section 11.12, “Redirecting requests based on the starting path to a pool”.
-
Listener (
Procedure
Source your credentials file.
Example
$ source ~/overcloudrc
Create a third pool (
pool_B
) on a load balancer (lb1
).NoteValues inside parentheses are sample values that are used in the example commands in this procedure. Substitute these sample values with values that are appropriate for your site.
Example
$ openstack loadbalancer pool create --name pool_B \ --lb-algorithm ROUND_ROBIN --loadbalancer lb1 --protocol HTTP
Add load balancer members (
192.0.2.50
and192.0.2.51
) on the private subnet (private_subnet
) to the pool (pool_B
):Example
In this example, the back-end servers,
192.0.2.50
and192.0.2.51
, are namedmember1
andmember2
, respectively:$ openstack loadbalancer member create --name member1 \ --address 192.0.2.50 --protocol-port 80 \ --subnet-id private_subnet pool_B $ openstack loadbalancer member create --name member2 \ --address 192.0.2.51 --protocol-port 80 \ --subnet-id private_subnet pool_B
Create a fourth pool (
static_pool_B
) on a load balancer (lb1
).Example
$ openstack loadbalancer pool create --name static_pool_B \ --lb-algorithm ROUND_ROBIN --loadbalancer lb1 --protocol HTTP
Add load balancer members (
192.0.2.100
and192.0.2.101
) on the private subnet (private_subnet
) to the pool (static_pool_B
):Example
$ openstack loadbalancer member create --name member3 \ --address 192.0.2.100 --protocol-port 80 \ --subnet-id private_subnet static_pool_B $ openstack loadbalancer member create --name member4 \ --address 192.0.2.101 --protocol-port 80 \ --subnet-id private_subnet static_pool_B
Create an L7 policy (
policy2
) on the listener (listener1
). The policy must contain the action (REDIRECT_TO_POOL
) and point to the pool (static_pool_B
). Insert the policy at position1
.Example
$ openstack loadbalancer l7policy create --action REDIRECT_TO_POOL \ --redirect-pool static_pool_B --name policy2 --position 1 listener1
Add an L7 rule to the policy (
policy2
) that uses a regular expression to match either/js
or/images
at the start of the request path.Example
$ openstack loadbalancer l7rule create --compare-type REGEX \ --type PATH --value '^/(js|images)' policy2
Add a second L7 rule to the policy (
policy2
) that matches the cookie (site_version
) to the exact string (B
).Example
$ openstack loadbalancer l7rule create --compare-type EQUAL_TO \ --key site_version --type COOKIE --value B policy2
Create an L7 policy (
policy3
) on the listener (listener1
). The policy must contain the action (REDIRECT_TO_POOL
) and point to the pool (pool_B
). Insert the policy at position2
.Example
$ openstack loadbalancer l7policy create --action REDIRECT_TO_POOL \ --redirect-pool pool_B --name policy3 --position 2 listener1
Add an L7 rule to the policy (
policy3
) that matches the cookie (site_version
) to the exact string (B
).Example
$ openstack loadbalancer l7rule create --compare-type EQUAL_TO \ --key site_version --type COOKIE --value B policy3
NoteIt is important to assign L7 policies with the most specific rules to a lower position, because the first policy whose rules all evaluate to True is the policy whose action is followed. In this procedure,
policy2
needs to be evaluated beforepolicy3
to avoid requests being sent to the incorrect pool.
Verification
-
Run the
openstack loadbalancer l7policy list
command and verify that the policies,policy2
andpolicy3
, exist. Run the
openstack loadbalancer l7rule list <l7policy>
command and verify that a rule with acompare_type
ofSTARTS_WITH
exists for each respective policy.Example
$ openstack loadbalancer l7rule list policy2 $ openstack loadbalancer l7rule list policy3
Additional resources
- loadbalancer pool create in the Command Line Interface Reference
- loadbalancer member create in the Command Line Interface Reference
- loadbalancer l7policy create in the Command Line Interface Reference
- loadbalancer l7rule create in the Command Line Interface Reference