进行中

我们将所有与服务插入相关的信息整合到一个 wiki 页面中

Quantum 中的服务插入模型

Launchpad 条目:

services-type

services-insertion-wrapper (folsom)

贡献者：Salvatore，Edgar Magana，Eugene，Ram Durairaj，Mani Ramasamy 和 Quantum 社区。

描述

此页面包含服务插入蓝图的设计规范。尽管规范已经相当完善，但尚未最终确定，因为一些细节仍可能发生变化，特别是关于实施计划而言。请订阅此页面以获取所有更新，或根据需要经常查看。该蓝图本身可以在此地址找到

此规范并未完全符合为 Quantum 设置的蓝图模板。这是因为我们给予了设计讨论更多的空间。一旦设计讨论完成，我们将拥有另一个使用蓝图模板的 wiki 页面。

高级描述

服务插入功能旨在定义一个在 Quantum 逻辑拓扑上运行 L4/L7 网络服务的框架。该框架将立即被 LBaaS 工作所利用；并且在不久的将来，其他高级服务将被插入到 Quantum 中（例如，VPN 和边缘防火墙）。

定义服务插入

在深入设计和实施讨论之前，值得以详细的方式定义什么是高级服务，以及如何将其插入到 Quantum 逻辑拓扑中。下图显示了 Quantum 的基本网络拓扑，一个逻辑路由器连接内部和外部网络；端口也显示在图中，用于 VIF、DHCP 服务器、路由器和浮动 IP 附件。

从之前的讨论中可以看出，服务可以以以下模式插入

路由模式 - 服务附加到逻辑路由器，然后成为多服务设备。

浮动模式（路径内）- 服务以独立方式运行。请注意，“浮动”插入并非自动是网络层插入，因为 L3 路由仍然可能发生。此模式也被称为“路径内或 bump-in-the-wire”插入。

参考上图，值得注意的是，即使在浮动模式下插入，高级服务仍然应该“连接”到网络。在上面的示例中，该服务连接到外部网络和内部网络。这应该反映在相关 Quantum 网络上的端口上，这些端口由高级服务本身拥有。

重定向模式（路径外）- 服务也以独立方式运行，但在这种情况下，流量首先发送到路由器实体，然后重定向到高级服务，最后将其发送回具有特定配置的路由器。特别是，如果将独立服务视为仅能提供特定服务的特殊路由器，则可以将此模型简化为第一个。此模式需要在路由实体进行特定更改，并且可能不会在 Grizzly 版本中实现。

这三种模式不是互斥的。下图显示了它们如何组合。参考下图，值得注意的是，插入到路由和浮动模式中的服务可以具有不同的实现。这意味着，例如，同一 Quantum 网络上的实例可以使用两种不同的解决方案进行负载平衡。

服务类型概念

就像 Quantum 插件允许使用多种技术来实现基本的逻辑拓扑一样，高级服务将使用类似的机制。但是，对于高级服务，相同类型服务的多个不同实现可能存在于同一部署中。有许多原因可以解释这一点，最重要的是让租户可以选择解决方案。服务类型概念试图解决多个、共存的服务提供商的需求。

服务类型定义可以被视为可以提供给租户的服务列表（及其提供商）。无论其插入模式如何，每个高级服务都应直接或间接地与单个服务类型关联。

服务类型资源可以描述如下

ServiceType:
{
  id: uuid,
  name: string,
  service_definitions: list<ServiceDefinition>
  default: {True¦False} # Only one service_type could be the default one. This is the service type which should be picked if none is specified in the API (think backward compatibility)
}

ServiceDefinition:
{
  id: uuid,
  name: string,
  type: enum(LB, VPN, FW) # or whatever you think is right
  provider: string # This ultimately must map to a python class (perhaps through a configuration variable)
  capabilities: list of API extensions which are enabled for this specify service provider
}

请注意，ServiceDefinition对象可以被视为它自己的资源，也可以被视为ServiceType的子资源。服务与服务类型之间的关联可以通过插入模式发生两种方式。

路由插入模式：高级服务将与 Quantum 逻辑路由器关联，而该路由器又与 service_type 资源关联；

为了确保向后兼容性，必须指定默认服务类型。这意味着将插入到路由器上的所有服务将共享相同的服务类型。

浮动插入模式：在创建高级服务时应显式指定服务类型；如果未指定，则使用默认服务类型。

在 API 层创建高级服务时，应指定以下两个参数之一

service_type_id # 浮动或路径外插入
router_id # 路由或路径内插入

不允许同时指定这两个参数。

带有服务类型概念的服务插入逻辑模型如图所示

该图显示了一组以路由模式（浅蓝色）部署的服务，以及以浮动模式（紫色）部署的服务。浅蓝色和紫色的服务与不同的服务类型相关联，然后这些服务类型可以映射到相同服务的不同实现。

将调用分派到插件

服务类型概念隐式允许为 API 调用提供不同的路径，因为它允许多个提供商为相同的请求提供服务。Eugene Nikanorov 也在这个 wiki 页面中讨论了这个主题：https://wiki.openstack.org/Quantum/ServiceIntegration

需要考虑两种设计方案

一个单独的插件，增加了为高级服务提供请求的能力；调用将然后重定向到特定于提供商的驱动程序。
多个独立的插件。每个插件特定于给定的服务提供商，并且可以实现一个或多个高级服务接口。

对于这两种设计方案，很明显，每个高级服务都应该有一个“服务插件接口”，这是插件端面向租户的 API 的对应物。核心 Quantum 插件类似地，定义了一个所有插件都必须实现的插件接口。

单插件方法

下图显示了一个实现核心和高级服务接口的 Quantum 插件。该插件能够解释 service_type 属性，并将调用分派到适当的特定于提供商的驱动程序。

对于这种方法，应该能够利用“mixin”机制，该机制在集成 DHCP 和 L3 服务时已经成功。应该允许通过添加高级服务处理能力来增强 Quantum 插件。在这种情况下，仍然只有一个 Quantum 插件；应在配置文件中指定适当的服务驱动程序。可以为每个服务指定多个驱动程序；服务驱动程序不应被视为实现服务的特定设备的驱动程序。相反，它是一个为给定提供商管理服务的驱动程序。

多插件方法

下图显示了采用这种方法时如何将服务类型映射到多个插件。每个插件实现特定于其实现的服务类型的接口。API 层具有一个分派器组件，该组件根据在 API 层指定的与高级服务关联的服务类型将调用转发到适当的插件。

Quantum 的一个原则是插件只需要实现插件接口。因此，不需要担心插件采用 mixin 机制；因此，另一个需要考虑的方面是可能存在同一类型的多个插件，并且将调用分派到一个插件或另一个插件的智能性应位于 API 层。

在这种情况下，可以同时配置多个插件。API 层需要弄清楚，对于每个路由器和/或高级服务，应该将 API 调用分派到哪个插件。还值得注意的是，插件不应被限制为实现单个高级服务。它很可能实现一组服务；这对于将与集成服务设备或应用程序交付控制器接口的插件尤其如此。

在这种情况下，上图可以概括如下（对配置文件的引用是此阶段的实现细节）

评估两种方法的优缺点

下图以非常高的层次描绘了单插件与多插件方法的不同流程。单插件方法在右侧报告，而多插件方法在左侧报告。

多个插件将需要 API 从不同的来源操作数据。即使每个插件都以相同的格式返回数据，我们仍然需要逻辑来处理从多个来源收集数据（在 GET 请求上），并在 POST/PUT/DELETE 上将命令分派到适当的目的地。
目前所有插件都已经实现了“mixin”方法，用于将 L2 功能与 L3 和 DHCP 功能增强。可以扩展此机制。
插件之间的兼容性（我们不需要从第一天开始担心的问题，但仍然是一个有趣的问题）
插件之间的交互；使用单个插件，数据模型拥有运行所需的所有信息。使用多个插件将需要与“基本”插件（或者在某些情况下甚至彼此之间）交互；可以通过插件接口实现这一点。
单个插件、多个驱动程序模型在 Quantum 数据库包含运行所需的所有信息时效果很好。这意味着诸如设备管理、资源分配等项目都使用所有插件共享的模型来描述。虽然可以通过引入特定于驱动程序的扩展或将这些功能移动到驱动程序来缓解这种情况，但显然这是一个更喜欢多插件方法的案例。

关于此蓝图的一些说明

此蓝图侧重于

提供基础设施，允许这些服务的实现来服务 API 请求；应该允许在 Quantum 部署中同时共存每个服务类别的多个实现。
定义一组 API 调用（以及支持逻辑和数据模型），用于定义服务可以附加到 Quantum 基本拓扑定义的逻辑拓扑中的位置、位置和方式；
允许这些服务的提供商公开特定于实现的扩展服务并将其通告给 API 用户。

定义可以插入哪些服务以及如何向租户呈现它们超出了此蓝图的范围。活动正在进行中以进行负载平衡服务；有关更多信息，请参阅 Quantum 框架中的 lbaas-* 蓝图。

此蓝图表达的大多数概念对 Quantum 社区来说并不新鲜，并且可以在由 Cisco 的 Edgar Magana 撰写的这个 wiki 页面中找到：https://wiki.openstack.org/QuantumServicesInsertion

其他说明（或者此设计规范不是关于什么）

可能存在服务插入发生在网络级别的情况，如 Sasha Ratkovic 的演示文稿所示。对于此蓝图的范围，我们将仅考虑路由器级别插入，假设网络级别插入可以简化为将服务插入到仅连接到单个网络的路由器的情况。
也绝对存在服务插入发生在端口级别的情况；在这种情况下，插入可以简单地表示为应用于端口本身的属性。例如，请参阅提出的 https://review.openstack.org/#/c/14262/。
Sasha Ratkovic 在 Openstack 设计峰会上提出的端口组概念也超出了此蓝图的范围。
无论高级服务将以新资源的形式实现（如 LBaaS 提案中所述），还是以策略的形式实现（如 Sasha Ratkovic 提案中所述），都超出了此蓝图的范围。

在此阶段，细心的读者可能会想知道此蓝图实际上是关于什么的。坦诚地说，通过定义一组（较小）我们想要解决的问题，以及一组（非常大）我们绝对不想解决的问题，可以说此蓝图实际上范围界定得很好，留下了一个非常窄、模糊的领域，其中可能包含或不包含此蓝图所涉及的项目。

工作任务

API

服务插入 API 可以在 Grizzly 发布周期中作为 Quantum 的扩展来实现，或者如果对此达成完全一致，则可以作为核心部分。服务插入支持需要在 Quantum API 中进行以下更改

服务类型管理。应提供对 ServiceType 对象进行 CRUD 操作的功能。
普通租户通常应仅允许读取
管理员将有权创建、修改和删除这些对象。此外，提供程序属性可能在返回给普通租户的响应中被隐藏。

注意：默认策略设置始终可以被覆盖，因为它们在 etc/policy.json 中指定

因此，Router 资源应扩展以下属性

  services:service_type_id # which refers to service_type object

每个高级服务都应允许指定服务类型 ID（用于浮动模式插入）或路由器 ID（用于路由模式插入）。

如果路由器支持多个服务，则可以允许租户启用或禁用路由器上的特定服务，具体取决于与路由器关联的服务类型。租户可以使用此功能将高级服务的使用量控制在配额限制内。

选项 1：资源操作 /routers/<router_id>/enable_service
- /routers/<router_id>/disable_service
选项 2：列表属性
选项 3：子资源 POST /routers/<router_id>/enabled_services

选项 1 目前是首选，因为它与“Openstack 方式”定义 API 执行资源操作的方式一致，这些操作超出了可以通过 HTTP 方法表达的范围。

服务配置

配置文件应包含对与各种高级服务对应的驱动程序/插件的引用。插件管理器将使用这些信息。

配置文件还可能包含服务类型定义，这些定义也可以存储在 Quantum 'core' 数据库中（请参阅“数据模型更改”部分）。

插件管理器

对于多插件方法，需要一种加载多个插件的机制。PluginAwareExtensionManager 不管理插件加载，但需要对其进行一些工作以处理插件特定的 API 扩展，因为它当前假定只有一个插件。

数据模型变更

如果将 ServiceType 定义建模到 Quantum DB 中，则需要两个模型类。ServiceType 类将与 ServiceDefinition 类具有 1:n 的关系。该类将具有一个属性，用于定义高级服务提供商的类型。这可以是模型中的另一个类，也可以从 Quantum 配置文件中提取。

ServiceProvider 定义也可以是另一个模型类，也可以是从配置文件中提取的信息。

基本插件接口的更改

服务插入功能将添加一个新接口，该接口可以作为要由“核心”插件继承的新 mixin 来实现（完全独立的类是可行的替代方案，但不太直接）。

管理 API 分派

此任务是关于实现前面本文档中讨论的单个插件/多个驱动程序或多插件方法。

当前实现中的潜在更改

浮动 IP：尽管随 Folsom 一起发布，但此功能实际上可能被视为“高级服务”，应该可能适合服务插入框架。
外部网关：这可能也可以被视为高级服务。例如，SNAT 服务。
DHCP：考虑我们今天通过代理实现的 DHCP 服务如何适应服务插入模型。我们没有专门暴露任何 DHCP API，而是为每个 dhcp_enable=True 的子网隐式地创建一个此服务的实例。我们可以选择将 DHCP 保持原样，也可以将其包含在服务插入模型中。

注意：对于上述情况，保持向后兼容性非常重要。

POC 提案

无论是否在 Quantum 之上实现实际的高级服务，都可以提供服务插入模型的 POC。此 POC 可以使用“虚拟”高级服务插件。另一种选择是将浮动 IP 并且可能还将外部网关概念重构为高级服务，并将其用于 POC。

将任务映射到 Grizzly 里程碑

任务	重要性
服务类型定义	必要
插件/驱动程序管理	必要
API 调用分派	必要
使用虚拟插件的 POC	高
使用 LBaaS 的 POC	必要
服务类型管理 API	未决定
服务类型在 Quantum DB 中	正常
将一些 L3 功能重构为高级服务	未决定

Neutron/ServiceInsertion

目录

进行中