高级层网络服务
此蓝图正在重新起草。 Ewan Mellor 和 Salvatore Orlando 欢迎您参与贡献。 此处内容尚未确定。
请注意，此蓝图目前正在更新。 其内容当前与 wiki.openstack.org/NetworkService 不一致
- Launchpad 条目: NovaSpec:network-service
- 创建时间: 2011 年 3 月 24 日
- 上次更新时间: 2011 年 4 月 13 日
- 贡献者: Ewan Mellor,Salvatore Orlando,Youcef Laribi
目录
总结
除了 NaaS 提供的基本 L2/L3 连接性之外，OpenStack 中的虚拟机实例还可以受益于高级网络服务，例如 DHCP、NAT、VPN 访问和负载均衡。 此蓝图不涉及任何特定的网络服务，也不旨在指定提供所有这些服务的单一服务。 相反，它应被视为任何 L4/L7 网络服务的通用规范；换句话说，它是创建高级网络服务蓝图的蓝图。
原理
NaaS 为连接云中运行的实例提供虚拟网络交换机的抽象；L4 到 L7 服务将使用此网络抽象；但是，它们仅通过其 API 与 NaaS 交互。 每个高级层服务都将带有其自身的通用 API。 例如，将有一个用于配置 NAT 的 API，以及一个用于配置负载均衡的 API。 与 NaaS 类似，API 与服务的实际实现分离，该实现将由适当的插件提供。
跟踪启用的高级服务
目标
目标 1：允许客户为其网络启用或禁用高级服务。 此外，服务提供商可以对这些服务收费，因此启用某个服务可能是一项可收费的事件。
目标 2：对于特定的高级网络服务，允许客户使用该服务本身提供的 API 来配置它；
目标 3：高级服务的 API 应基于开放源代码组件中可用的功能，该组件应作为 API 本身的“参考实现”采用（即：API 应代表多个实现提供的功能的“最大公约数”）。
目标 4：高级服务的 API 应定义可扩展性机制，以便允许客户使用供应商特定的扩展；这将允许第三方实现提供增值功能；
目标 5：允许 CSP 注册和配置提供服务的实际实现的插件。 CSP 应该能够根据需要选择和插入第三方技术。 这可能是为了扩展功能、提高性能或降低复杂性或成本。 例如，一个服务提供商可以选择基于加固的 Linux VM 提供其防火墙服务，但另一个服务提供商可以选择使用商业防火墙软件。 但是，也可能考虑客户能够提供自己的插件的情况。
目标 6：支持当前正在使用的网络拓扑结构（下面拓扑结构 1 和 2）。
拓扑结构
下面是一些示例网络拓扑结构。 对于每个拓扑结构，您可以考虑两种用例——希望在其拓扑结构中部署资源的客户，以及希望允许客户执行此操作的服务提供商。
关于 IP 配置策略（例如：注入或 DHCP），这与拓扑结构的选择无关；任何拓扑结构都可以与任何地址注入方案结合使用。
拓扑结构 1：隔离的租户网络
每个租户都有一个隔离的网络，租户通过 VPN 网关访问该网络。 租户可以在其网络上自由执行任何操作，因为它与其它租户的网络完全隔离。
这是今天的 NASA Nebula 模型。 当前使用每个租户一个 VLAN 以及一个 nova-network 实例作为 VPN 网关来实现。 请注意，可以使用不同的技术（例如，商业 VPN 网关，或使用 GRE 隧道代替 VLAN 进行隔离）来实现相同的模型。 此蓝图的一个目标是独立于底层实现技术来考虑该模型。
对于此拓扑结构，VPN 服务应与 NaaS 一起使用。
拓扑结构 2：防火墙服务
类似于拓扑结构 1，但 VPN 网关被防火墙服务取代。 防火墙的公共侧通常直接连接到 Internet。 防火墙由服务提供商提供。
在此拓扑结构中，防火墙服务应与 NaaS 运行
拓扑结构 3：客户自有网关
与拓扑结构 1 和 2 类似，但网关不是由云提供并由网络 API 管理的服务，而是客户提供的虚拟设备。
客户可以将大部分 VM 附加到其隔离的网络，但也可以配置一个（或多个）VM 具有两个接口，一个连接到隔离的网络，另一个连接到 Internet。 客户负责公共连接 VM 中的软件，并可能在其上安装网关或防火墙。
在此拓扑结构中，可能会发生以下情况：1 - 仅运行 NaaS，客户甚至可能不使用 NaaS 提供的 L3 服务； 2 - 客户提供的网络服务，例如 DHCP、防火墙和 NAT 与 NaaS 一起运行。
拓扑结构 4：多层级应用程序
与拓扑结构 3 类似，但客户预计运行 Web 服务器而不是运行网关或防火墙。 这些将通过公共接口提供内容，并通过专用网络与后端层联系。
在此拓扑结构中，很可能将有多个具有公共 Internet 连接的 Web 服务器和启用了多个高级服务。 例如，这些服务可以包括防火墙、IDS 和负载均衡
插件用例
在本节中，我们提供服务提供商可能希望在基础设施的各个点插入技术的示例。 其中一些技术是商业性质的。 在这种情况下，特定高级服务的蓝图将包括开放源代码替代方案的绑定，以便高级网络服务的 API 完全由开放源代码软件支持。 此蓝图的目标是服务提供商可以选择每个类别中不同的实现技术，无论是否使用商业技术或只是用另一种开放源代码技术替换一种开放源代码技术。
| 分类 |
| VPN 网关 |
| 负载均衡器 |
| 防火墙 |
需求
R1. 包括允许 CSP 注册/注销高级网络服务的功能。 此功能不应暴露给客户，除非他们被允许提供自己的插件；
R2. 提供允许客户为其网络启用或禁用高级服务的功能；
此外，每个特定的网络服务都有其自身的一组需求。 随着这些服务的规范的发布，我们将将其链接到此蓝图。 而且，当然，还有更多“通用”需求即将到来，不用担心！
设计思路
目前，尝试为高级网络服务提供设计是不切实际的。 因此，本节应被视为定义通用设计指南的首次尝试。 此外，与其处理特定的高级服务，不如呈现高级服务的抽象模型。
下图概述了高级服务如何与核心服务交互并向客户公开 API
- 每个服务都公开其自身的 API 接口；客户将使用此接口为其网络配置它们；
- 高级服务和 NaaS 是松散耦合的。 但是，它们可以使用 NaaS API 访问有关其管理的网络的的信息；
- 有一个管理器组件，其任务是为特定网络启用或禁用服务；例如，租户可能对一个网络使用 NAT 服务，而对另一个网络启用防火墙服务；此管理器组件可以位于 NaaS 空间内或在云控制器内运行；
- 就像 NaaS 一样，高级服务包含处理 API 请求和响应以及与其数据库交互的逻辑。 服务的实际实现将由插件提供。
