Layer 7 load balancing takes its name from the OSI model, indicating that the load balancer distributes requests to back-end pools based on layer 7 (application) data.

While layer 7 load balancing in general can theoretically be done for any well-defined layer 7 application interface, for the purposes of Octavia, L7 functionality refers only to the HTTP protocol and its semantics. Octavia accomplish the logic of layer 7 load balancing through the use of L7 Rules and L7 Policies. An L7 Rule is a single, simple logical test which evaluates to true or false. An L7 Policy is a collection of L7 rules, as well as a defined action that should be taken if all the rules associated with the policy match. 

To create a Policy you must go to your Listener, which is in turn inside the LB, and click on the Create L7 Policy button.Position of Policies

Once the Policy has been created, enter it. To create the rule set, click on the Create L7 Rule button.Position of Rules

L7 Rules

An L7 Rule is a single, simple logical test which returns either true or false. It consists of a rule type, a comparison type, a value, and an optional key that gets used depending on the rule type. An L7 rule must always be associated with an L7 policy.

Rules types

L7 rules have the following types:

• HOST_NAME: does a comparison between the HTTP/1.1 hostname in the request against the value parameter in the rule.
• PATH: compares the path portion of the HTTP URI against the value parameter in the rule.
• FILE_TYPE: compares the last portion of the URI against the value parameter in the rule. (eg. “txt”, “jpg”, etc.)
• HEADER: looks for a header defined in the key parameter and compares it against the value parameter in the rule.
• COOKIE: looks for a cookie named by the key parameter and compares it against the value parameter in the rule.

Comparaison types

L7 rules of a given type always do comparisons. The types of comparisons supported are listed below. Note that 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.

Invert

In order to more fully express the logic required by some policies, rules may have their result inverted. That is to say, if the invert parameter of a given rule is true, the result of its comparison will be inverted. For example, an inverted “equal to” rule effectively becomes a “not equal to”, and an inverted “regex” rule returns true only if the given regex does not match.

L7 Policies

An L7 Policy is a collection of L7 rules associated with a Listener, and which may also have an association to a back-end pool. Policies describe actions that should be taken by the load balancing software if all of the rules in the policy return true.

Policy logic

Policy logic is very simple: All the rules associated with a given policy are logically ANDed together. A request must match all the policy’s rules to match the policy. If you need to express a logical OR operation between rules, then do this by creating multiple policies with the same action (or, possibly, by making a more elaborate regular expression).

Policy actions

If an L7 policy matches a given request, then that policy’s action is executed. The following are the actions an L7 Policy may 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_TO_POOL: The request is forwarded to the back-end pool associated with the L7 policy.

Policy position

When multiple L7 Policies are associated with a listener, then the policies’ position parameter becomes important. The position parameter is used when determining the order in which L7 policies are evaluated. Here are a few notes about how policy position affects listener behavior:

• In the reference implementation of Octavia, 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 only evaluated after all of the above, and in the order specified by the position of the policy.
• L7 Policies are evaluated in a specific order (as defined by the position attribute), and the first policy that matches a given request will be 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 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 and the others will move down one 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 will just be appended to the list (i.e. its position will be equal to the number of policies in the list plus one).
• When policies are inserted, deleted, or appended to the list, the policy position values are re-ordered from 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, policy C’s position becomes 2.

L7 Policies vs programming

Let's try to explain the concepts just presented in other terms, making a parallelism with the typical selective syntax of programming languages. A single policies, in fact, can be seen as an if cycle, where the conditions are represented by the L7 Rules, linked together only through logical ANDs.

# The single Policy is verified when all the rules that compose it are verified.

# --- Policy1 ---
if (Rule1 and Rule2 and Rule3):		// Policy logic  
	action1                         // Policy action
# --- Policy2 ---
if (Rule1):							// Policy logic  
	action2                         // Policy action
# --- Policy3 ---
if (Rule1 and Rule2):				// Policy logic  
	action3                         // Policy action

When the Listener is invoked it will have to choose which action to perform, based on the Policy associated with it. The Listener will probe the list of its Policies, following a precise order, like a Switch/Case or an else if statement.

# The position of the Policy is important, because the Policies that are after the first verified Policy will be ignored.
if Policy1:			// Policy position
	action1
elif Policy2:		// Policy position
	action2
elif Policy3:		// Policy position
	action3
else:
	default pool	// If the listener has no default pool, then an error 503 is returned