Neutron/LBaaS/l7

L7 切换

背景

L7 切换得名于 OSI 模型，表明设备基于第 7 层（应用层）数据来切换请求。L7 切换也被称为“请求切换”、“应用切换”和“基于内容的路由”。

L7 交换机向外部世界呈现一个“虚拟服务器”，该服务器代表多个服务器接受请求，并根据使用应用程序数据确定哪个服务器或一组服务器应服务于任何给定请求的策略来分发这些请求。这允许针对特定类型的内容专门调整/优化应用程序基础设施。例如，一个服务器可以调整为仅提供图像，另一个用于执行服务器端脚本语言（如 PHP 和 ASP），而另一个用于静态内容（如 HTML、CSS 和 JavaScript）。

与较低级别的负载均衡不同，L7 切换不需要池（农场/集群）中的所有服务器都具有相同的内容。事实上，通常期望使用 L7 切换的负载均衡器配置期望后端服务器来自不同的池将具有不同的内容。L7 交换机能够根据 URI、主机、HTTP 标头和应用程序消息中的任何内容来定向请求。

Neutron LBaaS 中的 L7 切换

本文档中描述的 L7 切换功能计划在 Mitaka 发布周期中添加到 Neutron LBaaS 中。请注意，L7 切换仅适用于 LBaaS v2 API。由于 LBaaS v1 正在逐步淘汰，因此没有计划使 L7 切换功能与 Neutron LBaaS v1 协同工作。

值得注意的是，虽然理论上可以为任何定义良好的第 7 层应用程序接口完成 L7 切换，但就 Neutron LBaaS 而言，L7 功能仅指 HTTP 协议及其语义。

预计最初并非所有具有 Neutron LBaaS 驱动程序的负载均衡器供应商都会立即支持 L7 切换。但是，我们认为本文档中描述的 L7 切换功能应该足够通用，以至于所有能够执行 L7 功能的负载均衡器供应商都应该能够编写与 Neutron LBaaS L7 切换协同工作的驱动程序。

API 和逻辑变更

可以创建不一定与 Listener 关联的池
池直接关联到且仅关联到一个负载均衡器。
池与 Listener 具有“松耦合”（即，池可以通过 L7 策略或 default_pool 分配有效地关联到零个或一个 Listener）。
L7Policy 的 CRUD 操作
L7Rule 的 CRUD 操作

CLI 示例

neutron lbaas-create-listener listener1 ..... ( 创建 Listener)
neutron lbaas-create-pool pool1 ..... ( 创建池)
neutron --policy policy1 lbaas-create-l7policy --name "policy1" --description "我的描述" --listener "listener1" --action redirect_to_pool --pool "pool1" --position 1 (创建名为 'policy1' 的 l7 策略，并将其插入到 'listener1' 的 l7 策略列表的开头，该策略的动作是将请求重定向到池 'pool1')
neutron lbaas-create-l7rule rule1 --rule-type path --compare-type starts_with --value "/api" --policy policy (创建名为 'rule1' 的 l7 规则，并将其与策略 'policy1' 关联)
neutron lbaas-create-l7rule rule2 --rule-type header --compare-type equal_to --key "mycookie" --value "myvalue" --invert --policy policy1 (创建名为 'rule2' 的 l7 规则，并将其与策略 'policy1' 关联)

上述 L7 策略和规则创建现在应该启用以下逻辑

In listener1's configuration, redirect any given request to pool1 IF: The request URI path starts with "/api" AND cookie "mycookie" is NOT equal to "myvalue"

L7 规则

L7 规则是一个简单的逻辑测试，返回 true 或 false。它由规则类型、比较类型、值以及根据规则类型而使用的可选键组成。L7 规则必须始终与 L7 策略关联。

规则类型

L7 规则具有以下类型

hostname：规则在请求中比较 HTTP/1.1 主机名与规则中的 value 参数。
path：规则比较 HTTP URI 的路径部分与规则中的 value 参数。
file_type：规则比较 URI 的最后一部分与规则中的 value 参数。（例如，“txt”、“jpg”等）
header：规则查找在 key 参数中定义的标头，并将其与规则中的 value 参数进行比较。
cookie：规则查找由 key 参数命名的 cookie，并将其与规则中的 value 参数进行比较。

比较类型

给定类型的 L7 规则始终执行比较。我们支持的比较列表如下。请注意，并非所有规则类型都支持所有比较类型

regex：Perl 类型的正则表达式匹配
starts_with：字符串以...开头
ends_with：字符串以...结尾
contains：字符串包含
equal_to：字符串相等

反转

为了更充分地表达某些策略所需的逻辑，规则的结果可以反转。也就是说，如果给定规则的 invert 参数为 true，则其比较的结果将被反转。（例如，反转的“等于”规则实际上变成“不等于”，反转的“正则表达式”规则仅在给定的正则表达式不匹配时返回 true。）

L7 策略

L7 策略是与 Listener 关联的一组 L7 规则，并且可能还与后端池关联。策略描述了如果策略中的所有规则都返回 true/匹配，则负载均衡软件应采取的动作。

策略逻辑

策略逻辑非常简单：与给定策略关联的所有规则在逻辑上都通过 AND 连接在一起。请求必须匹配策略中的所有规则才能匹配该策略。

如果您需要表达规则之间的逻辑 OR 操作，请通过创建具有相同动作的多个策略来执行此操作（或者，通过创建更复杂的正则表达式）。

策略动作

如果 L7 策略匹配给定的请求，则该策略的动作将被执行。L7 策略可以采取以下动作

block：请求被拒绝，并带有适当的响应代码，不转发到任何后端池。
redirect_to_url：请求被发送到 redirect_url 参数中定义的 URL 的 HTTP 重定向。
redirect_to_pool：请求被转发到与 L7 策略关联的后端池（通常不是与 Listener 关联的默认池）。

策略位置

关于策略位置的一些说明

L7 策略按特定顺序（由“position”属性定义）进行评估，并且第一个匹配给定请求的策略将是

其动作被遵循的策略。

如果没有任何策略匹配给定的请求，则请求将被路由到 Listener 的默认池（如果存在）。
策略位置编号从 1 开始。
如果创建了一个位置与现有策略的位置匹配的新策略，则新策略将被插入到给定位置。
如果创建了一个未指定位置或指定位置大于列表中已有策略数量的新策略，则新策略将被附加到列表中。
当策略被插入、删除或附加到列表中时，策略位置值将从 1 开始重新排序，而不跳过数字。例如，如果策略 A、B 和 C 的位置值分别为 1、2 和 3，如果从列表中删除策略 B，则策略 C 的位置变为 2。

重要说明：目前，LBaaSv2 的参考实现使用 haproxy，haproxy 强制执行以下关于策略动作的顺序

block 策略优先于所有其他策略。
redirect_to_url 策略优先于 redirect_to_pool 策略。
redirect_to_pool 策略仅在评估完上述所有策略后，并按照策略的“position”顺序进行评估。

（事实证明，'block' 和 'redirect_to_url' 策略的几乎所有实际用途实际上都需要在 'redirect_to_pool' 策略之前发生这些情况，因此我们预计上述对策略评估顺序的施加不会给技术的大多数用户带来问题。）