跳转到： 导航, 搜索

NetworkContainers

  • Launchpad 条目: NovaSpec:netcontainers
  • 创建: 2011-04-06
  • 贡献者:

总结

Cisco 关于 OpenStack: 网络的提案 (NaaS)

我们正在提出 OpenStack: 网络的提案，作为一流的 OpenStack 服务。 虽然我们与其他 NetworkService 提案共享需求和许多设计理念/原则（许多贡献者同时参与这两个提案），但此蓝图的主要动机是向 OpenStack 社区预览整体提案和一些新的想法、用于 OpenStack: NaaS 考虑的概念。 此提案还扩展了其草案中指定的 NetworkService 要求。

发布说明

待定

设计

概述

OpenStack: NaaS 提供网络抽象层和一组 API（图 1），以实现： * 请求和获取 OpenStack:Compute 用于互连两个 VM 实例的网络连接，无论是单个虚拟网络（单个 vnic）还是多个 vnic 到不同的虚拟网络。<
> * 在适当的虚拟网络中插入网络服务（例如防火墙、负载均衡器、广域加速服务）；并动态请求“自适应”网络资源。<
> * 任何需要网络资源可见性或消耗的 OpenStack 应用程序或服务，例如：DR 应用程序、网络健康/监控服务、计费/结算服务等。<
> * 需要互连 OpenStack “区域”或地理分散的计算/存储资源的网络资源。<
> * 支持新服务（如虚拟私有云、企业扩展）所需的网络资源。<
> * 未来，此 NaaS 可以扩展以支持 SLA、网络级 QoS 和其他基于网络的审计/监控服务。<
>

图 1<
> Figure1.png

图 2 显示了 OpenStack:Network 逻辑组件。 Figure2.png

虚拟网络

如今的 nova:network 支持三种“网络模型”（a）FlatNetwork (b)FlatNetworkwithDHCP (c) VLAN with VPN GW instance。 该模型的缺点在其他提案中已有充分记录，而且它限制性很大。 在这种新的 Naas 模型中，网络抽象完全隐藏了用于实现网络分段的技术，例如：最初这可以通过 VLAN 标签来实现，未来不同的供应商可能会采用其专有/未来标准的分段方案，以提供可扩展性和灵活性。 考虑到这一点，虚拟网络主要是 L2 段（未来提供 L3 服务）。 这简化了所有其他 Openstack 服务对网络段的理解，并隐藏了“平台特定”的复杂性，使其对网络设备（物理和虚拟形式）而言更加简单。

=== NetContainer(NC) === 一个逻辑实体，最初为每个 OpenStack "项目" 创建。 每个 NetContainer 包含一个或多个虚拟网络段，以及一个或多个网络服务，并且未来可能嵌入一个或多个 NetContainers。

NetContainers 可以基于已定义的 NC 规格或从头开始实例化。

NC 规格

NC 规格为云服务提供商提供了一种“打包”其产品的方式，

  • 基于 Qos，例如：金牌、银牌或铜牌<
    > * 指定应用程序/服务特定 NC 规格的规格，例如：符合 HIPAA 标准的网络<
    > * 为特定租户或项目定义的简单网络资源，例如：项目用户允许创建多少个虚拟网络、最大 VM 数、支持的服务类型等。<
    >

NC 规格设想类似于 VM 规格，例如 m1.tiny、m1.large 等。 将有默认的基本 NC 规格，可以根据特定项目需求进一步修改。

NC 插件：插件是网络设备/供应商特定的“包装器”，用于配置物理/虚拟交换机和服务所需的网络资源。

图 3 显示了 NaaS 及其分层模型的层次结构。 虽然 NetContainers 可以基于已定义的可用 NC 规格请求和实例化，但 NaaS 也会提供直接的 NaaS API 来请求具有细粒度参数的 NC，以提供灵活性。

图 3 Figure3.png

在上面的图中，显示了网络段的逻辑表示。 云服务提供商 P1 与租户 T1，创建项目 Pr1，该项目托管应用程序 A1，具有三个虚拟网络 AT1、AT2 和 AT3。

所有 NetContainers 都应基于 NC 规格实例化。 一些规格将支持超出初始配置的修改，而另一些规格将锁定到最初实例化的相当严格的配置。 这取决于插件的功能，并为插件实现者提供了很大的灵活性。 提供更灵活容器的插件将具有优势，但这不会排除更基本的插件的用处。

图 4 显示了 OpenStack:Network 及其“网络设备”特定插件和各种 API 集。

图 4<
> Figure4.png

NaaS API 的可访问性，在授权方面，将遵循与 OpenStack:Compute 相同的模型

API 集 1: NC API

这些 API 提供了为项目创建和“管理”NetContainers 的能力； * NetContainer 可以基于 CSP（云服务提供商）分配给该项目的 NC 规格定义/创建 * 附加/创建 Net Container 的虚拟网络 * 在“适当”的虚拟网络段“节点”处实例化/附加网络服务 * 查询/监控 NetContainer 健康状况 * 未来监控

API 集 2: 网络服务 API

这些是一组子集 API，使我们能够定义服务插入和服务的“引导”参数。

“配置/管理”服务本身不在此 API 集的范围内。 “配置/管理”每个服务是供应商特定的，并且很难将其全部对齐到一个模型下。 此外，每个服务可能都有自己的 SDK 和不同的部署模型来支持，这使得将其全部置于此集合中非常复杂。 但是，OpenStack 应为众所周知的服务（如防火墙、负载均衡器）提供“通用”网络服务配置。

使用此 API，租户可以

  • 选择服务/类型服务，项目希望消耗和使用<
    > * “自定义”服务 – 配置网络“插入”参数<
    > * 列出/识别消耗的服务和健康状况<
    >

API 集 3: NC 规格 API

这组 API 主要由 CSP 用于定义与网络和网络服务相关的“资源”/服务产品。 开放讨论：这些 API 在多大程度上可以进一步开放给项目/租户以自定义“规格”。

规格示例：三层应用程序，具有私有、公共虚拟网络，具有 FW 和 LB 服务，VPN GW 附加

使用此 API 集，CSP/租户可以： * 为项目和服务产品创建/管理模板。<
>

在下一节中，我们将讨论两个主要层，NaaS:Core 和 Naas:Plugins，如何交互及其各自的职责

组件职责

NaaS:Core

持有 NetContainer 实例的引用

  • 提供容器配置 API <
    > * 暴露可用 NetContainers 及其属性的目录 <
    > * 允许对 NetContainers 进行操作/运行时控制 <
    > * 讨论点：将计算/存储映射到容器？ 或者计算服务是否管理？
  • 选项 1：NaaS 拥有连接，因此计算使用参数向 NaaS 注册 VM
  • 选项 2：NaaS 向计算通告容器，计算管理连接

NaaS:Plug-ins

  • 拥有可用的产品（哪些容器可用）<
    > * 拥有将容器映射到网络设备环境（例如：网络段方案 – VLAN ID、QinQ 等）<
    > * 拥有容器配置，包括资源分配、位置、服务等<
    > * 支持标准但可扩展的格式，用于 !netcontainer 类型定义和 !netcontainer 实例请求<
    > * 报告错误的标准方法，例如缺少信息、未知元素、无效配置等<
    > * 查询特定容器类型的实际可用性的 API（了解哪些资源可用，哪些已被消耗）<
    > * 处理与 NaaS:Core 的异步通信

用例

用例 1: 为 Openstack 项目创建一个网络资源

配置容器的工作流程

  • 客户从 NaaS 产品中选择 !netcontainer 服务（如果有）<
    > * 客户提供所需参数以指定配置偏好、策略等<
    > * NaaS 从客户信息创建请求文档<
    > * NaaS 将请求文档传递给插件<
    > * 插件解析文档并映射到资源需求<
    > * 插件根据可用资源评估资源需求<
    > * 插件根据容器请求配置资源<
    > * 插件返回新容器的句柄（REST URL）<
    >

用例 2: 网络服务请求网络资源

  • 防火墙的插入请求另一个内部虚拟网络和外部网络段

用例 3: 虚拟私有云/企业扩展

  • 在 NC 中创建一个虚拟网络<
    > * 创建 VPN/加速服务实例并将其附加到“私有”网络段<
    >

用例 4: 网络调度器

  • 支持多个 !OpenStack:Compute 区域并与 nova-scheduler 结合调度网络资源。

API 定义

这组 API 允许 Openstack 服务和“应用程序”请求网络容器、删除网络容器、修改网络容器 (NC) 属性、列出所有可用的 NC 规格并创建新的 NC 规格。 这些 API 由 Openstack 计算或其他服务以编程方式使用。

API 定义和数据模型将尝试遵循 Openstack:Compute API 1.1，如 https://docs.openstack.org/openstack-compute/developer/cs-devguide.pdf 中所述

JSON 是 OpenStack:Network APIs 的默认数据序列化方式。

身份验证

OpenStack: Network APIs 将遵循与 OpenStack:Compute 相同的身份验证模型，并且可能支持多种身份验证方案（OAuth、基本身份验证、令牌）等。

关键概念

租户：这可能映射到项目或组织，具体取决于调用 NaaS API 的系统。 这是一个唯一的名称/标签，用于标识 NC 的所有权。 租户可以映射到 Openstack:compute 服务调用的项目。 “数据服务”也可以使用租户结构来为存储相关服务创建网络容器。 这也使其能够应对 OpenStack:compute 和其他消费者应用程序/服务可能发生的更改，例如：OpenStack: Computer 从项目演变为 ORG/vDC/vApp 之类的结构。

规格：网络资源属性方面的容器定义。 例如：虚拟网络数量、附加的网络服务、未来的区域亲和性。

API 摘要 (正在进行中)

租户操作

API 定义 请求 请求体
注册租户 POST OpenStack:Networks API URL/config/tenant/create 租户信息
注销租户 GET OpenStack:Network API URL/config/tenant/UID/delete 租户信息
列出租户 GET OpenStack:Network API URL/tenants GET OpenStack:Network API URL/tenants/detail

示例: 创建租户

POST {APP-URI}/config/tenant/create

请求体


<tenant>
  <name>TenantABC1</name>
  <description>Optional description here</description>
</tenant>

响应代码

  • 201 Created – 租户已创建。 Location 标头提供已创建租户的 URL。<
    >400 Bad Request – 请求存在问题，例如缺少数据
  • 404 Not Found – 指定的 domainId 域未找到。
  • 409 Conflict – 名称与现有租户冲突

NC 规格操作

API 定义 请求 请求体
创建 NC 规格 POST OpenStack:Networks API URL/config/ncflavor/create NC 规格信息
修改 NC 规格 <actions>
删除 NC 规格
列出 NC 规格 GET OpenStack:Network API URL/ncflavors GET OpenStack:Network API URL/ncflavors/detail

NetContainer 操作

API 定义 请求 请求体
创建 NetContainer POST OpenStack:Networks API URL/config/netcontainer/create NetContainer 信息
修改 Net Container <actions>
删除 Net Container
列出 NetContainers GET OpenStack:Network API URL/netcontainers GET OpenStack:Network API URL/netcontainers/detail

网络服务附件

API 定义 请求 请求体
附加服务 网络服务信息
配置服务 <serviceUID>
列出容器的服务

开放 问题

  • NetContainers 定义 – 它与 OVF netspec 有何关系？ 我们能重叠和利用 OVF 规范多少？<
    > * 我们如何解决实例化 NC 或删除它时的“依赖关系”？<
    > * 显式支持的服务枚举？<
    > * 如何支持安全组之类的模型？ 灵活性<
    >

BoF 议程和讨论

使用本节记录 BoF 期间的笔记；如果将其保留在批准的规范中，请用于总结讨论内容并记录任何被拒绝的选项。

从 "https://wiki.openstack.org/w/index.php?title=NetworkContainers&oldid=17842" 检索而来