Layer 7 Load Balancing¶

什么是 L7 负载均衡？¶

L7 负载均衡的名称来源于 OSI 模型，表明负载均衡器基于第 7 层（应用层）数据将请求分发到后端池。L7 负载均衡也称为“请求切换”、“应用负载均衡”、“基于内容的路由”、“基于内容的切换”和“基于内容的平衡”。

L7 负载均衡器由一个监听器组成，该监听器代表多个后端池接受请求，并根据使用应用数据确定哪些池应该服务任何给定请求的策略分发这些请求。这允许针对特定类型的内容专门调整/优化应用基础设施。例如，一组后端服务器（池）可以调整为仅提供图像，另一组用于执行 PHP 和 ASP 等服务器端脚本语言，还有一组用于静态内容，如 HTML、CSS 和 JavaScript。

与较低级别的负载均衡不同，L7 负载均衡不需要负载均衡服务背后的所有池都具有相同的内容。事实上，通常期望 L7 负载均衡器期望来自不同池的后端服务器将具有不同的内容。L7 负载均衡器能够根据 URI、主机、HTTP 标头和应用消息中的其他数据定向请求。

Octavia 中的 L7 负载均衡¶

本文档中描述的 L7 负载均衡功能是在 Mitaka 版本周期（Octavia 0.8）中添加到 Neutron LBaaS 和 Octavia 中的。

虽然从理论上讲，L7 负载均衡可以针对任何定义良好的第 7 层应用接口完成，但对于 Octavia 而言，L7 功能仅指 HTTP 协议及其语义。

它是如何工作的？¶

Neutron LBaaS 和 Octavia 通过使用 L7 规则和 L7 策略来实现 L7 负载均衡的逻辑。L7 规则是一个简单的逻辑测试，其结果为真或假。L7 策略是 L7 规则的集合，以及如果与策略关联的所有规则匹配时应采取的定义操作。

下面将详细介绍这些概念及其具体细节。

L7 规则¶

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

另请参阅：Octavia API 参考

规则类型¶

L7 规则具有以下类型

HOST_NAME：规则将请求中 HTTP/1.1 主机名与规则中的值参数进行比较。
PATH：规则将 HTTP URI 的路径部分与规则中的值参数进行比较。
FILE_TYPE：规则将 URI 的最后一部分与规则中的值参数进行比较。（例如，“txt”、“jpg”等）
HEADER：规则查找在键参数中定义的标头，并将其与规则中的值参数进行比较。
COOKIE：规则查找由键参数命名的 cookie，并将其与规则中的值参数进行比较。
SSL_CONN_HAS_CERT：如果客户端已提供用于 TLS 客户端身份验证的证书，则规则将匹配。这并不意味着证书有效。
SSL_VERIFY_RESULT：此规则将匹配 TLS 客户端身份验证证书验证结果。值为“0”表示证书已成功验证。大于“0”的值表示证书验证失败。此值遵循 openssl-verify 结果代码。
SSL_DN_FIELD：规则查找在键参数中定义的 Distinguished Name 字段，并将其与规则中的值参数进行比较。

比较类型¶

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

REGEX：Perl 类型的正则表达式匹配
STARTS_WITH：字符串以...开头
ENDS_WITH：字符串以...结尾
CONTAINS：字符串包含
EQUAL_TO：字符串相等

反转¶

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

L7 策略¶

L7 策略是与监听器关联的 L7 规则的集合，并且可能与后端池关联。策略描述了如果策略中的所有规则都返回 true，则负载均衡软件应采取的操作。

另请参阅：Octavia API 参考

策略逻辑¶

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

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

策略操作¶

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

REJECT：使用适当的响应代码拒绝请求，不转发到任何后端池。
REDIRECT_TO_URL：向定义的 URL 发送 HTTP 重定向请求 redirect_url 参数。
REDIRECT_TO_POOL：将请求转发到与 L7 策略关联的后端池。

策略位置¶

当多个 L7 策略与监听器关联时，策略的 position 参数变得重要。 position 参数用于确定评估 L7 策略的顺序。以下是一些关于策略位置如何影响监听器行为的说明

在 Octavia 的参考实现（haproxy amphorae）中，haproxy 强制执行以下关于策略操作的排序
- REJECT 策略优先于所有其他策略。
- REDIRECT_TO_URL 策略优先于 REDIRECT_TO_POOL 策略。
- REDIRECT_TO_POOL 策略仅在评估上述所有策略之后，并按照 position 策略指定的顺序进行评估。
L7 策略按特定顺序（由 position 属性定义）进行评估，并且第一个匹配给定请求的策略将是执行其操作的策略。
如果没有任何策略匹配给定的请求，则请求将被路由到监听器的默认池（如果存在）。如果监听器没有默认池，则将返回错误 503。
策略位置编号从 1 开始。
如果创建了一个位置与现有策略的位置匹配的新策略，则新策略将插入到给定的位置。
如果创建新策略时未指定位置，或者指定的位置大于列表中已有的策略数量，则新策略将附加到列表的末尾。
当策略被插入、删除或附加到列表中时，策略位置值将从 1 开始重新排序，而不跳过数字。例如，如果策略 A、B 和 C 的位置值分别为 1、2 和 3，如果从列表中删除策略 B，则策略 C 的位置将变为 2。

L7 用法示例¶

有关常见 L7 用法示例的烹饪书，请参阅 Layer 7 Cookbook

Layer 7 Load Balancing