VPN 服务支持 QoS¶
https://bugs.launchpad.net/neutron/+bug/1727578
目前，没有办法设置 VPN 服务的带宽。本规范提出了一种设置 VPN 服务带宽限制的方法。
问题描述¶
目前，Neutron VPNaaS 提供站点到站点 VPN 服务，但其带宽消耗不受监管，因为 VPN 隧道会消耗 ISP 或其他组织提供的外部公共带宽。这意味着它不是免费的。OpenStack 提供商或用户需要为有限的带宽付费。因此，节省资源是必要的。
目前，OpenStack 环境之外的物理设备配置无法被 OpenStack 修改，但我们可以整形出站流量。VPN 服务提供安全保障，但不应滥用底层网络的带宽，从而影响其他流量。
用例¶
考虑一个 OpenStack 公有云已在真实数据中心部署。云企业用户有一个需求，其中一个应用程序应连接到其私有网络 20.0.0.0/24，但对于其他流量，仍使用 OpenStack 提供的原始网络功能。网络拓扑图如下
+
+--------------------+ + |DataCenter
|VM1 | | |external network
|nic IP: 10.0.0.11 | | +-------------------------------+ | +----+
|default via 10.0.0.1+---+ |Default Router | | | |
| | +-----------------+Interface: 10.0.0.1 +------+ | |
+--------------------+ | |gw: 172.24.4.11 | | | |
OpenStack | |route: 20.0.0.0/24 via 10.0.0.5| | | |
private . | | | | | |
network . | +-------------------------------+ | | |
| | | |
subnet: 10.0.0.0/24 | | | |
+--------------------+ | | | |
|VM2 | | +--------+ |Internet
|nic IP: 10.0.0.12 | | | | |
|default via 10.0.0.1+---+ | | |
| | | | | |
+--------------------+ | | | |
| | | |
. | +--------------------------------+ | | | +-------------------------------+
. | |VPN Router | | | | |Vendor GW Router |
| |Interface: 10.0.0.5 | | | | |peer vpn service running |
+-----------------+gw: 172.24.4.12 +-----+ | +-------+hold private subnet 20.0.0.0/24|
+--------------------+ | |VPN service running | | | | | |
|VMX | | | | | | | | |
|nic IP: 10.0.0.13 | | +--------------------------------+ | +----+ +-------------------------------+
|default via 10.0.0.1+---+ |
| | | |
+--------------------+ | |
| |
+ +
如该图所示，企业用户拥有私有网络中的许多 VM，分配的 IP 来自私有子网 10.0.0.0/24。连接了两个路由器，默认 路由器 用于正常的网络功能，例如 NAT、浮动 IP、路由。 VPN 路由器 主要用于 VPN 流量处理，还包含其他流量的 NAT 和路由。这两个路由器都连接到外部网络，即真实数据中心中的物理底层网络。OpenStack 中的 VPN 路由器和另一站点中的 Vendor GW 路由器通过互联网保持 VPN 对等关系。
针对 VM 出站流量有两种场景
OpenStack 私有网络中的 VM 访问普通网站，首先将网络数据包发送到其网关，该网关位于
默认 路由器上。然后通过数据中心设备发送到互联网。OpenStack 私有网络中的 VM 访问另一站点私有网络 20.0.0.0/24，仍然首先将网络数据包发送到其网关 10.0.0.1，然后检查路由表，20.0.0.0/24 的下一跳是 10.0.0.5，该地址位于
VPN 路由器上。网络流量将基于现有的 VPN 隧道发送到 Vendor 私有站点。
如图所示，应在 VPN 路由器的 qg-XX 端口上设置 QoS 策略，以限制出站 VPN 流量。
本规范侧重于 VPN 出站流量的 QoS，因此对于 neutron-vpnaas，本规范将侧重于与 VPN 服务相关的路由器。对于通常通过互联网在隧道模式下设置 VPN 服务的通用用例，我们将仅介绍隧道类型 VPN 服务的 QoS 支持。
提议的变更¶
我们建议 VPN 服务 资源接受 Neutron QoS 策略。一旦创建了 ipsec 站点 连接，QoS 策略将应用于 VPN 路由器的 qg-XX 端口，因为 ESP 封装将使用 qg-XX 端口的 IP 访问其他站点。
因此，有三个部分需要协同工作
DB 相关更改，包括添加新表
qos_vpnservice_policy_bindings和数据模型更改。API 更改，包括扩展 API 以接受 Neutron QoS 策略。
引入一个新的 l3 agent 扩展，以扩展处理路由器上 QoS 策略安装的能力。
备选方案¶
接受 QoS 参数并在我们自己的基础上实现 QoS 功能。
直接将 QoS 策略应用于路由器接口，但这会影响东西向流量。
数据模型影响¶
在本规范中，QoS 数据模型和功能将由 Neutron 提供，因此 vpnservices 表需要维护与 Neutron QoS 策略的关系。
作为 VPN QoS 功能的一部分，添加了以下新表
CREATE TABLE `qos_vpnservice_policy_bindings` (
`vpn_service_id` varchar(36) NOT NULL,
`qos_policy_id` varchar(36) NOT NULL,
UNIQUE KEY `vpn_service_id` (`vpn_service_id`),
KEY `qos_policy_id` (`qos_policy_id`),
CONSTRAINT `qos_vpn_service_policy_bindings_ibfk_1` FOREIGN KEY (
`qos_policy_id`) REFERENCES `qos_policies` (`id`) ON DELETE CASCADE,
CONSTRAINT `qos_vpn_service_policy_bindings_ibfk_2` FOREIGN KEY (
`vpn_service_id`) REFERENCES `vpnservices` (`id`) ON DELETE CASCADE
);
REST API 影响¶
拟议属性
EXTEND_FIELDS = {
'qos_policy_id':{'allow_post': True, 'allow_put': True,
'validate': {'type:uuid': None},
'is_visible': True,
'default': None}
}
在 VPN 服务 创建/更新中，一些示例。允许用户传递 qos_policy_id。
创建/更新 VPN 服务 请求
POST /v2.0/vpn/vpnservices
{
"vpnservice": {
"subnet_id": null,
"qos_policy_id": "a36c20d0-18e9-42ce-88fd-82a35977ee8c",
"router_id": "66e3b16c-8ce5-40fb-bb49-ab6d8dc3f2aa",
"name": "myservice",
"admin_state_up": true
}
}
Response:
{
"vpnservice": {
"router_id": "66e3b16c-8ce5-40fb-bb49-ab6d8dc3f2aa",
"status": "PENDING_CREATE",
"name": "myservice",
"external_v6_ip": "2001:db8::1",
"admin_state_up": true,
"subnet_id": null,
"project_id": "10039663455a446d8ba2cbb058b0f578",
"tenant_id": "10039663455a446d8ba2cbb058b0f578",
"external_v4_ip": "172.32.1.11",
"id": "5c561d9d-eaea-45f6-ae3e-08d1a7080828",
"description": "",
"qos_policy_id": "a36c20d0-18e9-42ce-88fd-82a35977ee8c"
}
}
PUT /v2.0/vpn/vpnservices/{service_id}
{
"vpnservice": {
"name": "NEW VPN SERVICE NAME",
"description": "Updated description",
"qos_policy_id": "a36c20d0-18e9-42ce-88fd-82a35977ee8c"
}
}
Response:
{
"vpnservice": {
"router_id": "881b7b30-4efb-407e-a162-5630a7af3595",
"status": "ACTIVE",
"name": "NEW VPN SERVICE NAME",
"admin_state_up": true,
"subnet_id": null,
"project_id": "26de9cd6cae94c8cb9f79d660d628e1f",
"tenant_id": "26de9cd6cae94c8cb9f79d660d628e1f",
"id": "41bfef97-af4e-4f6b-a5d3-4678859d2485",
"description": "Updated description",
"qos_policy_id": "a36c20d0-18e9-42ce-88fd-82a35977ee8c"
}
}
QoS 策略应用细节¶
引入此功能的原因，例如，我们更改了下面的用例，我们在 默认 路由器 上部署 vpn 服务，删除了 VPN 路由器。这意味着普通流量和 VPN 流量将通过 默认 路由器，然后我们将 Neutron QoS 策略应用于 默认 路由器 的 qg-XX 端口，这将限制所有带宽，因此 VPN 的带宽可能会性能较低，或者我们可以说它与预期不一致。
目前，Neutron 提供了 QoS 功能，但并非针对某些感兴趣的流。在这里，我们将专注于 VPN 流量。为此，我们将结合 iptables 和 tc。选择它们的原因是，iptables 可以通过 ipsec VPN 转换协议（例如 esp、ah-esp 协议）、接口（数据包将流出）以及在隧道模式下运行时的本地封装 IP 来标记 VPN 感兴趣的流。此外，我们需要在发送到底层网络之前整形 vpn 流量，因此将在路由器的命名空间中安装一些新的 iptables 规则。此外，fwmark 更易于扩展，例如 ipchains。
我们将引入一个新的 tc 包装器，它将使用 htb，并提供分类算法。然后，开发人员可以轻松实现其他复杂的流量控制。这意味着我们将扩展 Neutron 仓库中的当前 tc_lib。并且 vpn_qos 将基于此。
正如上述描述，将引入一个新的 L3 agent 扩展，就像 fip_qos 完成的那样。我们建议将其命名为 vip_qos，它将安装与 VPN 服务 绑定的路由器的命名空间中的适当 iptables 规则。然后，用户或管理员可以将 QoS 功能应用于 默认 路由器，而不影响其他网络流。
安全影响¶
无
通知影响¶
没有预期的更改。
其他最终用户影响¶
用户将在创建/更新 VPN 服务 时指定 qos_policy。
性能影响¶
这将节省数据中心底层网络的带宽。
其他部署者影响¶
无
开发人员影响¶
开发人员可以使用新的 tc 包装器来做其他事情，因为它功能强大，可以支持其他流控制功能。但如果可能，它可能会与 openstack/neutron-classifier 发生冲突，因为它提供了流量的定义。所以我们可能会重新考虑一下。
实现¶
负责人¶
zhaobo
工作项¶
添加 DB 模型并扩展表列。
扩展 VPN API 以接受 QoS 策略。
扩展新的 tc 包装器，该包装器基于流量分类器功能支持分类算法。
扩展新的 L3 agent 扩展
vip_qos。添加 API 验证代码以验证 Neutron 中创建的 qos_policy 的访问/存在性。
为 Neutron-vpnaas 添加 UT。
添加 API 测试。
更新 CLI 以接受 QoS 字段。
文档工作。
依赖项¶
无
测试¶
需要单元测试、功能测试、API 测试和场景测试。
文档影响¶
需要更新 Neutron API 参考。
