跳转到： 导航, 搜索

NetworkService

~+此蓝图已被取代

please refer to this wiki page for latest updates on openstack's network service

术语表

NaaS: Networking as a Service (网络即服务)

Openstack-NaaS: 此蓝图提出的面向客户的服务。这与现有的 nova-network 区分开来。

更高层服务: 可能由 NaaS 创建的网络启用的 L4/L7 网络服务。

OpenStack NaaS API: openstack-NaaS 暴露的面向客户的 API。

VIF: Virtual InterFace (虚拟接口)。VM 的网络接口，也称为 vNIC。

总结

此蓝图的目标是在 OpenStack 云中添加一个一流的、面向客户的服务，用于管理网络基础设施。这将允许服务提供商向其客户提供“网络即服务”(NaaS)。

此蓝图讨论了在 openstack-NaaS 中启用功能和能力的目标、用例、需求和设计思路，以便能够创建和管理网络，这些网络被视为共享连接的虚拟端口集合，为 VM 实例提供第 2 层和可能的第 3 层连接。

更高层服务，例如防火墙、NAT、VPN 和负载均衡，将由通过暴露的 API 与 NaaS 通信的独立服务提供。L4/L7 服务在此 wiki 页面上讨论。

原理

NaaS 的主要目标是为 OpenStack 用户提供一种服务，以向其 VM 实例提供第 2 层网络；使用 NaaS 创建的网络实际上可以被视为虚拟网络交换机，以及连接到它的相关网络设备，可能跨越云中的所有计算节点。除了提供第 2 层服务外，NaaS 还旨在提供第 3 层网络，即 IP 配置管理和 IP 路由配置。

NaaS API 应该与网络服务的实现解耦，该实现应该通过插件提供。这意味着 NaaS 不强制执行任何特定的网络模型，无论是在第 2 层（例如：VLAN、IP 隧道），还是在第 3 层（例如：基于文件系统的注入、DHCP）。

目标

目标 1: 允许客户和 CSP 创建、删除和桥接网络。网络可以是私有的，即仅对特定客户可用，也可以是共享的。也可以考虑仅在特定客户组之间共享的网络。

目标 2: 允许客户和 CSP 管理其网络的虚拟端口，并将云中可用的实例或其他网络设备（物理或虚拟）连接到它们。

目标 3: 允许客户和 CSP 通过将云中的桥接设备连接到其网络来扩展其网络到远程站点；桥接设备将然后桥接到适当的远程站点。

目标 4: 允许客户和 CSP 管理其网络的 IP 配置。应支持 IPv4 和 IPv6。可以与网络关联零个、一个或多个 IP 子网。

目标 5: 允许客户和 CSP 定义子网之间的 IP 路由。路由可以在同一虚拟网络中的子网之间定义，也可以在同一租户拥有的不同虚拟网络中的 IP 子网之间定义。

目标 6: 允许客户和 CSP 通过提供统计信息（例如每个网络、端口或 VIF 传输和接收的总字节数）来监控网络。还应提供基于 IP 的统计信息。

目标 7: 允许客户和 CSP 安全地配置网络、端口和连接到它们的设备的网络策略。这些策略可以包括，例如，端口安全策略、访问控制列表、高可用性或 QoS 策略（这些通常在物理网络交换机上可用）。仅支持一组基本的配置选项；剩余的网络策略应假定为插件特定的，并且始终通过 API 扩展机制进行配置。

目标 8: 允许 CSP 注册和配置提供网络服务实际实现的插件。CSP 应该能够根据需要选择和插入第三方技术。这可能是为了扩展功能、提高性能或降低复杂性或成本。

用例

用例 1：创建私有网络并将实例连接到它

相关拓扑：每个租户都有一个隔离的网络。租户可以自由地对其网络做任何事情，因为它与其它租户的网络完全隔离。这是今天的 NASA Nebula 模型，使用每个租户一个 VLAN 实现。请注意，即使可以使用不同的技术（例如，用于隔离的 GRE 隧道而不是 VLAN）来实现相同的模型，但这不会改变模型本身的性质。

  1. 客户使用 NaaS API 创建一个网络；
  2. 成功后，NaaS API 返回新创建网络的唯一标识符；
  3. 客户使用 NaaS API 配置网络上的逻辑端口；
  4. 客户调用 Cloud Controller API 运行一个实例，指定网络和虚拟端口；
  5. Cloud Controller API 将请求分派到计算服务；
  6. 计算服务创建 VM 和 VIF。对于每个 VIF，它要求 NaaS 将其插入到客户在 (4) 中指定的端口和网络。

用例 2：将实例连接到默认公共网络

相关拓扑：类似于 nova network 当前支持的“Flat”模式。来自不同客户的实例都部署在同一个虚拟网络上。在这种情况下，Core NaaS 服务可以提供端口隔离策略以确保 VM 安全性。

  1. 客户使用 NaaS API 检索公共网络；
  2. 成功后，NaaS API 返回一个唯一的网络标识符列表；客户从该列表中选择一个网络；
  3. 客户使用 NaaS API 配置网络上的逻辑端口；
  4. 客户调用 Cloud Controller API 运行一个实例，指定网络和虚拟端口；
  5. Cloud Controller API 将请求分派到计算服务；
  6. Nova 计算服务创建 VM 和 VIF。对于每个 VIF，它要求 NaaS 将其插入到客户在 (4) 中指定的端口和网络。

此用例与前一个用例的主要区别在于，客户使用预配置的网络而不是创建它。另一个需要讨论的点是是否应该允许客户管理公共网络的端口。或者，计算服务可以在联系 NaaS API 时隐式创建端口。

用例 3：注册桥接器以将云网络连接到其他站点

相关拓扑：客户本地数据中心扩展到云中，互连不同云中的网络。虽然实际实现可以通过多种方式提供，但我们关注的是抽象模型：跨越两个或多个不同管理域的网络中的单个连接域。

  1. 客户使用 NaaS API 为其网络注册一个桥接器；
  2. 成功后，NaaS API 返回桥接器标识符；
  3. 客户使用 NaaS API 提供桥接器配置（例如：远程端点、端口、凭据）；
  4. 客户使用 NaaS API 在网络上为桥接设备创建一个虚拟端口；
  5. 客户使用 NaaS API 将桥接设备插入网络

用例 4：检索网络的统计信息

  1. 客户使用 NaaS API 检索一个特定的网络；
  2. 成功后，NaaS API 返回网络标识符；
  3. 客户使用 NaaS API 检索网络的统计信息。可以使用过滤器来指定应检索哪些数据（例如：总的 RX/TX 字节数），以及应检索网络哪些组件的统计信息（整个网络、特定端口、特定 VIF）。
  4. NaaS 调用实现插件以检索所需的信息；
  5. NaaS API 返回统计数据，客户处理这些数据。

注意：此用例的参与者可以是客户或更高层的监控或计费服务，例如：根据网络使用情况向客户收费的服务。

用例 5：配置网络策略

  1. 客户使用 NaaS API 检索一个特定的网络；
  2. 成功后，NaaS API 返回网络标识符；
  3. 客户使用 NaaS API 在网络上强制执行策略；例如，策略可以在特定端口上指定最大比特率，或阻止整个网络上的特定协议；
  4. NaaS 调用实现插件以强制执行策略；
  5. NaaS API 通知用户操作的结果。

用例 6：配置 IP 子网并将实例连接到它

  1. 客户使用 NaaS API 检索一个特定的网络；
  2. 成功后，NaaS API 返回网络标识符；
  3. 客户使用 NaaS API 创建一个 IP 子网，通过指定 CIDR（或替代网络地址和子网掩码）和网关；
  4. 成功后，NaaS API 返回新创建子网的唯一标识符；
  5. 客户调用 NaaS API，以便将已经连接到其 L2 网络之一的 VIF 连接到新创建的子网；
  6. NaaS 验证输入数据的合理性（例如：VIF 连接到适当的网络）；
  7. NaaS 调用 IP 配置管理插件，为提供的 VIF 提供适当的配置；

用例 7：配置两个 IP 子网之间的路由

对于此用例，我们假设客户已经拥有应路由的两个子网的标识符（URI、UUID）。

  1. 客户调用 NaaS API 在两个子网之间创建路由
  2. NaaS API 使用 CIDR 和网关地址为两个子网创建适当的路由
  3. NaaS 返回新创建路由的唯一标识符

IP 路由的创建方式（例如：操作实例上的路由表、操作超visor 上的路由表、配置路由器虚拟设备等）是插件特定的。路由属性，例如距离、成本和权重也应作为扩展 API 的一部分，因为它们不要求提供基本功能。

插件用例

在本节中，我们提供服务提供商可能希望插入 NaaS 以提供 L2/L3 网络的示例技术。其中一些技术本质上是商业的。在这种情况下，此蓝图将包括一个开源替代方案的绑定，以便 NaaS API 完全由开源软件支持。此蓝图的目标是服务提供商可以选择不同的实现技术。

分类
分布式虚拟交换机
数据中心间隧道
IP 地址管理

需求

R1. 添加一个一流的、面向客户的服务，用于通过 RESTful API 管理和配置网络基础设施。该服务应被称为 openstack-NaaS，它暴露的 API 应被称为 OpenStack NaaS API。

R2. 修改 nova-compute 以通过其公共 API 调用 openstack-NaaS 获取网络详细信息，而不是像今天调用 nova-network 那样。

... 还有更多内容，请不要担心！

设计思路

目前，尝试为 NaaS 提供设计还为时过早。因此，本节应被视为定义通用设计指南的首次尝试。

从非常高的层次来看，网络服务及其与其他实体（计算服务、数据库、插件）的交互可以总结如下：

Naas-Core-Overview.png

  • Nova 计算服务不应了解超visor 的网络堆栈，并使用 NaaS API 来将 VIF 插入网络（这与当前 nova 设计略有不同，在当前设计中，网络管理器的部分代码 - 即 setup_compute_network - 也被计算服务使用）；
  • 应允许用于 Layer-2 网络和 Layer-3 网络的独立插件；至少对于 Layer-3 网络，应期望多个插件；例如，一个插件可以通过 DHCP 提供 IP 配置，而另一个插件可以使用基于代理的配置。
  • Layer-3 网络虽然是 NaaS 的一部分，但不是强制性的。在最简单的形式下，NaaS 可以仅提供 Layer-2 连接；
  • Layer-2 和 Layer-3 插件都可以附加到 NaaS；但是，如果未提供 Layer-3 插件，NaaS 应引发一个 NotImplemented 错误，用于每个 L3 API 请求。
  • NaaS API 服务于来自客户和计算服务的请求。特别是，计算服务与 NaaS 相关的职责如下：
    • 将虚拟接口插入/拔出由 NaaS 管理的虚拟网络；
    • 将虚拟接口附加/分离到 NaaS 中配置的 IP 子网。
  • “插件分发器”组件负责将 API 请求分发到适当的插件（该插件不属于 NaaS）；
  • 对于 Layer-2 网络，插件使用专有机制在超visor 上强制执行网络/端口配置；
  • 类似地，Layer-3 网络插件使用专有机制强制执行 IP 配置和路由；
  • 虽然该图假设插件在 NaaS 节点上有一个“管理器”组件和代理“组件”，但这并非要求，因为 NaaS 应完全不了解插件实现；“插件网络代理”不是必需的。提供核心 NaaS 服务实现的插件的设计不在本蓝图的范围内；
  • NaaS 将有关网络和 IP 子网的信息存储在其自己的 DB 中。NaaS 数据模型在本节的其余部分中将更详细地讨论；

NaaS 的数据模型

目前 nova-network 使用 nova 数据库，将信息存储在 networks 表中。它还使用其他一些表，例如 fixed_ips 和 floating_ips；每个项目都与一个网络相关联。为了实现 NaaS 与其他 nova 服务之间的完全分离，那么 NaaS 应该有自己的数据库。在 nova DB 表中仍然会与网络相关联；但是，网络标识符将代表由 NaaS 创建的网络（而不是 networks 表中的行主键）的唯一标识符。Nova 中可能会缓存其他元素，例如与实例关联的 IP，但 Nova 将不再是记录网络信息的系统。

此外，值得考虑网络和项目之间的 1:N 关联，这已经由 NovaSpec:nova-multi-nic 蓝图要求，甚至 N:M 关联，如果我们想支持在不同项目之间共享的网络。

下图报告了 NaaS 数据模型的概览。与 Layer-2 网络相关的实体以绿色显示，而 Layer-3 实体以蓝色显示。

NaaS-Data-Model.png

Network 实体定义 Layer-2 网络；其最重要的属性是：一个唯一的标识符（可以是 URI 或 UUID），所有者以及网络的名称。诸如与网络关联的 VLAN ID 之类的详细信息属于插件提供的特定实现，因此不应在 NaaS DB 中。插件（或它们连接的系统）将拥有自己的数据库。一个 Network 可以与多个逻辑端口关联。除了端口号之外，Port 实体还可以定义端口的管理状态并缓存有关通过端口本身流动的流量的统计信息。端口与 VIF 之间以 1:1 的关系关联。VIF 表跟踪虚拟网络接口到端口的连接。虽然 VIF 不是由 NaaS 创建的，但了解哪些 VIF 连接在哪里很重要。

至于 L3 实体，IP_Subnet 是最重要的一个；其属性可以是子网 CIDR（或网络地址/子网掩码）以及可选的默认网关。用于子网的 IP 配置方案也应成为此实体的一部分，假设 NaaS 可以同时使用多个方案。IP_Subnet 实体中的每个条目都可以与一个或多个 IP 地址关联。这些是当前为给定网络分配的地址（通过 DHCP 租约或静态机制），并与 VIF 关联。虽然 IP 地址显然可以与单个 VIF 关联，但 VIF 也可以与多个 IP 地址关联。最后，IP Routes 实体将配置了 IP 路由的子网链接起来。IP 路由的属性，例如成本和权重，是插件特定的，因此不应成为此实体的一部分，该实体可能简化为 IP_Subnet 表上的自关联。

NaaS API

草稿文档：attachment:NaaS_API_spec-draft-v0.1.docx

可能的 IP 配置策略

每个 VIF 都需要一个 IP 地址（IPv4 或 IPv6）；这些由以下方案之一提供给 VM，这些方案可以由不同的插件实现：

方案 1：代理：使用 VM 内部的代理来设置 IP 地址详细信息。该代理将通过特定于虚拟化的方案（XenStore、VMCI 等）或通过更通用的方案（例如虚拟 CD-ROM）接收配置。当然，此方案需要在 VM 镜像中安装代理。

方案 2：DHCP：配置 VM 以使用 DHCP（通常是默认设置），并在启动 VM 之前配置 DHCP 服务器。这可以是私有 DHCP 服务器，仅对该 VM 可见，也可以是更广泛共享的服务器。

方案 3：文件系统修改：在启动 VM 之前，通过直接修改其文件系统来设置 IP 配置。

先决条件

每个 VM 多个 VIF。Cactus 中 OpenStack 中没有，但预计将在 Diablo 中通过 NovaSpec:multi-nic 和 NovaSpec:multinic-libvirt 添加到 Nova。这需要所有受支持的虚拟化技术（当前 KVM/libvirt、XenAPI、Hyper-V、ESX）。

开发资源

尚未做出任何承诺，但 Citrix、Grid Dynamics、NTT、Midokura 和 Rackspace 已经提供了开发资源。

我们将确定如何在规范接近完成时分担开发负担。

正在进行的工作

已经注册了以下与 Openstack 网络服务相关的蓝图：

另外

  • Erik Carlin 正在制定 OpenStack Networking API 的草案规范。
  • 如前所述，正在进行支持每个实例多个虚拟网卡的工作。NovaSpec:nova-multi-nic
  • Ilya Alekseyev 已经注册了 NovaSpec:distros-net-injection 蓝图，以便支持针对多个 linux 发行版的文件系统 IP 配置注入（nova 现在仅支持基于 debian 的发行版）。Christian Berendt 也注册了一个类似的蓝图，NovaSpec:injection
  • Dan Wendlandt 已经注册了 NovaSpec:openvswitch-network-plugin，用于基于 Open vSwitch 的 NaaS 插件

讨论

Erik Carlin 创建了一个 Etherpad 用于一般的 NaaS 讨论。请在此处添加您的评论 here

其他讨论资源

Bexar 设计峰会讨论的 Etherpad：http://etherpad.openstack.org/i5aSxrDeUU

Bexar 设计峰会替代讨论的 Etherpad：http://etherpad.openstack.org/6tvrm3aEBt

Bexar 设计峰会讨论的幻灯片：http://www.slideshare.net/danwent/bexar-network-blueprint

从 "https://wiki.openstack.org/w/index.php?title=NetworkService&oldid=17846" 检索