Chapter 11. Implementing layer 7 load balancing
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. 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. 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. Note You cannot create L7 policies and rules with UDP load balancers. Additional resources Section 11.4, "Layer 7 load-balancing rule types" 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 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 Section 11.3, "Layer 7 load-balancing rules" 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 Section 11.4, "Layer 7 load-balancing rule types" 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 Section 11.7, "Layer 7 load-balancing policies" 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. Note You cannot create L7 policies and rules with UDP load balancers. Additional resources Section 11.3, "Layer 7 load-balancing rules" 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 Section 11.3, "Layer 7 load-balancing rules" 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 Section 11.7, "Layer 7 load-balancing policies" 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 of 1 , 2 and 3 respectively, if you delete policy B from the list, the position for policy C becomes 2 . Additional resources Section 11.7, "Layer 7 load-balancing policies" 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 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 values that are appropriate for your site. Example 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 Add an L7 rule that matches all requests to a policy ( policy1 ). Example 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 a compare_type of STARTS_WITH exists. Example 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 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 values that are appropriate for your site. Example 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 In this example, the back-end servers, 192.0.2.10 and 192.0.2.11 , are named member1 and member2 , respectively: 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 Add an L7 rule that looks for /js at the start of the request path to the policy. Example Create an L7 policy ( policy2 ) with an action ( REDIRECT_TO_POOL ) and add the listener ( listener1 ) pointed at the pool. Example Add an L7 rule that looks for /images at the start of the request path to the policy. Example Verification Run the openstack loadbalancer l7policy list command and verify that the policies, policy1 and policy2 , exist. 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 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 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 values that are appropriate for your site. Example 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 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 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 a compare_type of EQUAL_TO exists for the policy. Example 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 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 values that are appropriate for your site. Example 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 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 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 a compare_type of EQUAL_TO exists for the policy. Example 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. Important 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 Create a second pool ( login_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 values that are appropriate for your site. Example 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 named member1 : 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 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 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 a compare_type of REGEX exists. Example 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. Important 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 Create a second pool ( login_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 values that are appropriate for your site. Example 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 named member1 : 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 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 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 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 string INVALID . Example Verification Run the openstack loadbalancer l7policy list command and verify that the policies, policy1 and policy2 , exist. Run the openstack loadbalancer l7rule list <l7policy> command and verify that a rule with a compare_type of REGEX exists for policy1 and a rule with a compare_type of EQUAL_TO exists for policy2 . Example 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 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 values that are appropriate for your site. Example 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 In this example, the back-end servers, 192.0.2.10 and 192.0.2.11 , are named member1 and member2 , respectively: 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 Add an L7 rule to the policy that matches the hostname api.example.com . Example 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 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 a compare_type of EQUAL_TO and STARTS_WITH , respectively, both exist for policy1 . Example 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" . Procedure Source your credentials file. Example Create a third pool ( pool_B ) 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 values that are appropriate for your site. Example Add load balancer members ( 192.0.2.50 and 192.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 and 192.0.2.51 , are named member1 and member2 , respectively: Create a fourth pool ( static_pool_B ) on a load balancer ( lb1 ). Example Add load balancer members ( 192.0.2.100 and 192.0.2.101 ) on the private subnet ( private_subnet ) to the pool ( static_pool_B ): Example 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 position 1 . Example 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 Add a second L7 rule to the policy ( policy2 ) that matches the cookie ( site_version ) to the exact string ( B ). Example 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 position 2 . Example Add an L7 rule to the policy ( policy3 ) that matches the cookie ( site_version ) to the exact string ( B ). Example Note It 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 before policy3 to avoid requests being sent to the incorrect pool. Verification Run the openstack loadbalancer l7policy list command and verify that the policies, policy2 and policy3 , exist. 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 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
source ~/overcloudrc openstack loadbalancer listener create --name http_listener --protocol HTTP --protocol-port 80 lb1 openstack loadbalancer l7policy create --name policy1 --action REDIRECT_PREFIX --redirect-prefix https://www.example.com/ http_listener openstack loadbalancer l7rule create --compare-type STARTS_WITH --type PATH --value / policy1 openstack loadbalancer l7rule list policy1 source ~/overcloudrc openstack loadbalancer pool create --name static_pool --lb-algorithm ROUND_ROBIN --loadbalancer lb1 --protocol HTTP 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 openstack loadbalancer l7policy create --name policy1 --action REDIRECT_TO_POOL --redirect-pool static_pool listener1 openstack loadbalancer l7rule create --compare-type STARTS_WITH --type PATH --value /js policy1 openstack loadbalancer l7policy create --name policy2 --action REDIRECT_TO_POOL --redirect-pool static_pool listener1 openstack loadbalancer l7rule create --compare-type STARTS_WITH --type PATH --value /images policy2 openstack loadbalancer l7rule list policy1 openstack loadbalancer l7rule list policy2 source ~/overcloudrc openstack loadbalancer pool create --name pool2 --lb-algorithm ROUND_ROBIN --loadbalancer lb1 --protocol HTTP openstack loadbalancer l7policy create --name policy1 --action REDIRECT_TO_POOL --redirect-pool pool2 listener1 openstack loadbalancer l7rule create --compare-type EQUAL_TO --type HOST_NAME --value www2.example.com policy1 openstack loadbalancer l7rule list policy1 source ~/overcloudrc openstack loadbalancer pool create --name pool2 --lb-algorithm ROUND_ROBIN --loadbalancer lb1 --protocol HTTP openstack loadbalancer l7policy create --name policy1 --action REDIRECT_TO_POOL --redirect-pool pool2 listener1 openstack loadbalancer l7rule create --compare-type ENDS_WITH --type HOST_NAME --value .example.com policy1 openstack loadbalancer l7rule list policy1 source ~/overcloudrc openstack loadbalancer pool create --name login_pool --lb-algorithm ROUND_ROBIN --loadbalancer lb1 --protocol HTTP openstack loadbalancer member create --name member1 --address 192.0.2.10 --protocol-port 80 --subnet-id secure_subnet login_pool openstack loadbalancer l7policy create --name policy1 --action REDIRECT_TO_POOL --redirect-pool login_pool listener1 openstack loadbalancer l7rule create --compare-type REGEX --key auth_token --type COOKIE --value '.*' --invert policy1 openstack loadbalancer l7rule list policy1 source ~/overcloudrc openstack loadbalancer pool create --name login_pool --lb-algorithm ROUND_ROBIN --loadbalancer lb1 --protocol HTTP openstack loadbalancer member create --name member1 --address 192.0.2.10 --protocol-port 80 --subnet-id secure_subnet login_pool openstack loadbalancer l7policy create --action REDIRECT_TO_POOL --redirect-pool login_pool --name policy1 listener1 openstack loadbalancer l7rule create --compare-type REGEX --key auth_token --type COOKIE --value '.*' --invert policy1 openstack loadbalancer l7policy create --action REDIRECT_TO_POOL --redirect-pool login_pool --name policy2 listener1 openstack loadbalancer l7rule create --compare-type EQUAL_TO --key auth_token --type COOKIE --value INVALID policy2 openstack loadbalancer l7rule list policy1 openstack loadbalancer l7rule list policy2 source ~/overcloudrc openstack loadbalancer pool create --name api_pool --lb-algorithm ROUND_ROBIN --loadbalancer lb1 --protocol HTTP 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 openstack loadbalancer l7policy create --action REDIRECT_TO_POOL --redirect-pool api_pool --name policy1 listener1 openstack loadbalancer l7rule create --compare-type EQUAL_TO --type HOST_NAME --value api.example.com policy1 openstack loadbalancer l7rule create --compare-type STARTS_WITH --type PATH --value /api policy1 openstack loadbalancer l7rule list policy1 openstack loadbalancer l7rule list policy2 source ~/overcloudrc openstack loadbalancer pool create --name pool_B --lb-algorithm ROUND_ROBIN --loadbalancer lb1 --protocol HTTP 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 openstack loadbalancer pool create --name static_pool_B --lb-algorithm ROUND_ROBIN --loadbalancer lb1 --protocol HTTP 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 openstack loadbalancer l7policy create --action REDIRECT_TO_POOL --redirect-pool static_pool_B --name policy2 --position 1 listener1 openstack loadbalancer l7rule create --compare-type REGEX --type PATH --value '^/(js|images)' policy2 openstack loadbalancer l7rule create --compare-type EQUAL_TO --key site_version --type COOKIE --value B policy2 openstack loadbalancer l7policy create --action REDIRECT_TO_POOL --redirect-pool pool_B --name policy3 --position 2 listener1 openstack loadbalancer l7rule create --compare-type EQUAL_TO --key site_version --type COOKIE --value B policy3 openstack loadbalancer l7rule list policy2 openstack loadbalancer l7rule list policy3