跳转到： 导航, 搜索

NetworkServiceDiablo

Warning.svg 旧设计页面

此页面曾用于帮助设计 OpenStack 之前版本的一个特性。它可能已经被实现，也可能没有。因此，此页面可能不会被更新，并且可能包含过时的信息。上次更新时间为 2013-12-12

Network Service Proposal for Diablo

概述

此提案是几位社区成员之间讨论的结果，他们独立提交了 Openstack 中网络功能的蓝图。这些提案包括

(在此处列出提案)

此页面描述了在 Diablo 时间范围内以实验形式交付的目标服务。

Network Services Model

下图描述了两件事

  1. 软件服务架构，以及虚拟网络服务和 IPAM 服务与 Nova 的关系
  2. 用于描述 Diablo 时间范围内的虚拟网络拓扑的逻辑网络架构元素

OpenStackNetworkServicesDiablo.jpg

Network Services Actors

Nova Refactoring and Responsibilities

建议对 Nova 网络进行以下两种重构

  1. 将网络功能组合成更集中的模型，但不要删除对现有选项的支持
  2. 为现有的 flat（静态）、flat（DHCP）和 VLAN 选项添加对虚拟网络服务支持

Virtual Networking Service

(这个项目需要一个名称。“Quantum”被提出过。)

虚拟网络服务将在 Diablo 中承担以下职责

  1. 提供用于管理 L2 网络抽象（“虚拟网络”？）的 API
  2. 提供身份验证、验证等
  3. 提供错误处理
  4. 分解请求（如果需要）
  5. 将请求分派到适当的插件
  6. 资源消耗查找服务
  7. 插件能力目录

Virtual Networking Service Plug-in

VNS 的插件将在 Diablo 中承担以下职责

  1. 接收并验证来自 L2 服务的请求
  2. 将逻辑抽象映射到实际的物理/虚拟服务实现/配置
  3. 向 L2 服务通告能力

IPAM Service

  • 今天：Nova 只是从预定义的块中分配 IP 地址
  • 网络块细分，将大块划分为较小的子网
  • DHCP（应至少提供 dns-masq 等效项和插件支持）
  • IPAM 服务的消费者 - openstack 服务（nova、LBaaS、Layer 2 等）
  • IPv4 和 IPv6
  • 多租户（重叠的 IP 范围）
    • 公共地址空间
    • 私有（重叠）地址空间
    • 必须能够将 IP 关联到租户/项目和网络段
  • 应存储 IP 地址、默认网关、子网（dhcp 选项：dns 服务器、ntp 等）
  • 策略 - 分配 - 块使用方式的规则（为特定目的保留某些地址等）
  • 问题：我们如何处理同一 L2 段上的多个 IP 子网？
    • 策略和优先级？
  • 问题：静态 IP？
    • nova 保留，然后持有？
    • 消费者是否可以指定要获取的 IP？
  • 需要支持浮动 IP
  • IPAM 服务是存储库，而不是“actor”（存储信息并回答查询，不会主动推送它）*

IPAM Service Plug-in

  • 需要支持 DHCP 功能的插件
  • 需要了解是否有对更广泛 IP 服务的插件的要求

Container Service

如果容器服务在 Diablo 时间范围内被定位，它将

  1. 提供用于管理容器抽象的 API
    • 容器表示作为单元进行管理的资源逻辑组
    • 初步重点是网络和网络服务
  2. 提供容器“口味”目录
  3. 提供定义容器“口味”的方式
  4. 提供实例化容器“口味”的方式
  5. 提供动态构建容器定义的方式
  6. 提供在运行时修改容器实例的机制。
  7. 分解请求并根据需要与其他网络服务通信。

Virtual Network Components

Network Segment

Diablo 时间范围内的虚拟网络拓扑的中心元素是网络段

  1. 表示单个 Layer 2 网络子网
  2. 通过“端口”提供访问
  3. 连接到“端口”的任何设备都可以与段上的任何其他设备通信

Virtual Interface (VIF)

VIF 表示从连接到网络的设备（例如，VM、网络服务或网关）的接口（例如，虚拟 NIC）

Port

端口表示到网络段的连接。端口可以单独配置，并且可以连接到任何有效的 VIF。但是，当 VIF “连接”到网络段时，VIF 和端口之间存在 1:1 的关系。

Other items proposed for discussion (captured by Dan W)

L2 Service Discussion Notes (Tuesday 4/26/2011) 

  • ** Tenant/Logical API ***

基本抽象：- 接口（由接口服务公开，例如，nova、防火墙、负载均衡器等）    - 网络（由 L2 服务公开）。  - 端口，与网络相关联（由 L2 服务公开） 

- 租户可以调用 L2 服务将接口“连接”到端口（可能是在 Port 对象上的“PUT”操作。此连接的语义是接口设备与接口服务（例如，VM NIC）之间的“虚拟电缆”和 L2 网络上的端口。“- 提到像 nova 这样的服务也可以作为此 API 的客户端，例如，自动将 VM 的公共 NIC 创建并连接到共享公共网络。- L2 网络的“口味”概念未确定。这可能更适合于像 donabe 这样的更高级别的容器服务，但有些人担心提供商然后可以使用具有多种 L2 段实现方式（例如，vlan 与 overlay）的插件。  

  • ** The Network Edge:  ***

  - 必须能够描述 L2 网络服务管理的交换机与接口服务之间的连接点。   - 可以将其视为元组 (interface-id, interface-location)，其中 interface-id 是租户/逻辑 API 中使用的逻辑接口标识符，而 interface-location 是接口服务（例如，XenServer 与 KVM 与 VMware ESX 与 VMware with vDS）可以理解的接口的当前位置的描述。   - Openstack 的部署必须确保它具有能够理解接口服务将使用的所有格式的 L2 网络服务，否则 L2 服务将无法实际连接所有接口。应该有一种机制/握手来在设置时检查这一点。- 沟通此信息的具体机制尚未定义。有些人提到一个用于映射的显式目录，另一些人提到一个管理 API 以支持查询。  

  • ** Plugin Interface ****

- L2 网络插件接口将映射到租户/逻辑 API 和任何管理 API。- 插件“之上”存在代码以实现 API 解析、执行基本验证、根据服务提供商的要求强制执行 API 限制以及使用 keystone 授权请求。   - 如果希望使用多个插件，一种选择是根据定义的策略将调用分派到适当插件的“元插件”。   - 插件可以潜在地与多种类型的设备通信（例如，与 Cisco 物理交换机和 Open vSwitch 通信的插件。从这个意义上说，插件不同于“驱动程序”，驱动程序通常与它所谈论的“事物”类型之间存在一对一的对应关系。（注意：此讨论发生在一些人去吃午饭之后，因此我们可能没有完全达成共识）。  

  • ** Network & Scheduling ****

- 没有详细探讨，但似乎需要让 L2 插件定义可以在其中创建 L2 网络的“区域”概念。例如，如果使用 VLAN，这可能映射到单个 L2 域的数据中心“pod”。- 也提出了网络信息告知调度的其他原因，例如，能够满足主机的带宽保证。此主题可能需要与 nova 中合适的同事进行专门讨论。 

  • ** Other ***

- L2 服务的临时名称仍然是“quantum”。网络容器概念是“donabe”。- 讨论了 L2 桥接是 L2 服务的一部分还是“插入”到 L2 网络的更高级别服务的一部分。没有达成最终决定，因为双方都有相当强烈的意见。我们应该在峰会结束前努力最终确定这一点。 

Retrieved from "https://wiki.openstack.org/w/index.php?title=NetworkServiceDiablo&oldid=38099"