Manila/Kilo Network Changes

简介

本文档旨在概述 Kilo 版本中 Manila 网络方面的设计变更。

用例

简单的实验室配置

一位 Manila 开发者想要为新的硬件平台编写驱动程序。该硬件存在于实验室中，连接到网络交换机，没有 VLAN 标记。开发者对交换机或路由器没有管理访问权限，虽然他对存储控制器有管理访问权限，但他没有物理访问权限来修改布线。存储控制器配置了静态 IP 地址用于其管理和数据接口。好的一面是，开发者已经获得了实验室管理员的同意，为他预留了同一子网上的 IP 地址池，他可以用这些地址创建 SVM。

网络：扁平，单个子网，多个 SVM
安全性：无
其他考虑因素：无

客户现场 POC 安装

一位已经使用 OpenStack 和一些商业存储的客户想要试验 Manila，以了解它并评估它的用处。客户已经拥有多个存储控制器，但它们都在生产环境或其他概念验证或测试项目中被使用。客户拥有所有相关设备的管理员访问权限和物理访问权限，但不想为了快速 POC 而打扰现有环境。需要共享一个存储控制器，并且共享的控制器通过没有 VLAN 标记的网络交换机连接。

网络：扁平，单个子网，单个 SVM
安全性：无
其他考虑因素：无

企业私有云

一个 IT 部门为一家公司的各个业务部门构建了一个中等规模的私有云。这些业务部门都相互了解，并依赖简单的访问控制来保护数据免受窥探和意外损坏。构建云的主要动机是“aaS”模式，它允许 IT 部门更高效、更快速地响应。该公司是 NAS 存储（在商业存储控制器上）的大用户，IT 部门希望在生产环境中推出 Manila，以开始提供 NASaaS，以便其用户最终可以停止使用传统的 NAS。IT 部门对其网络设计拥有完全控制权，包括物理和逻辑方面。由于私有云的所有“租户”都存在于同一公司内，因此大量基础设施是共享的，包括 Active Directory、LDAP 和 Kerberos，并且租户之间没有完全隔离的防火墙。

网络：扁平，多个子网，多个 SVM
安全性：租户不应能够访问其他租户的共享资源
其他考虑因素：无

公共云服务

一家向公众提供基于 OpenStack 的云服务的公司希望部署 Manila 到生产环境中，并开始提供 NASaaS 服务，与块存储和对象存储一起提供。租户期望其数据具有完全的隐私性，无论是在传输过程中还是在静态时。一些客户拥有 VPN 连接，这些 VPN 连接连接到他们的公司办公室和云端，他们期望只有他们自己的虚拟机才能访问这些连接。

网络：分段，多个子网，多个 SVM
安全性：租户不应能够检测到其他租户的存在
其他考虑因素：网络分段可能是 VLAN、VXLAN 或 GRE

公共云（租户自助）

租户希望在公共云（或潜在的私有云）的租户上下文中启动并交付完整的 Manila。

网络：扁平，VPC，多个 SVM
安全性：由租户所有者定义并包含在上下文中
其他考虑因素：租户网络可能位于任何数量的 SDN 技术之上。

独立安装用于管理现有 NAS

一个 IT 部门希望向用户提供 NASaaS，但目前使用某种专有的云软件。他们决定使用 Manila，但不使用 OpenStack 的其余部分。商业存储控制器专门用于此目的。

网络：扁平，多个子网，多个 SVM
安全性：租户不应能够访问其他租户的共享资源
其他考虑因素：无

自动化测试系统

一位 Manila 开发者希望能够在虚拟环境中快速设置 Manila 进行测试。Manila 和 OpenStack 的其余部分都将运行在一个虚拟机内，通过虚拟路由器提供与外部世界的网络连接。要测试的存储控制器未虚拟化，并与多个测试节点共享。开发者可以访问配置存储控制器，但运行测试的虚拟机位于不同的位置，仅通过 IP 地址连接到存储控制器。

网络：扁平，单个子网，单个 SVM
安全性：无
其他考虑因素：无

现场演示

一位开发者希望在笔记本电脑上安装完整的 OpenStack 安装，包括 Manila，以便在断开互联网连接的情况下在公共场合进行演示。所有内容都是虚拟化的。

网络：扁平，单个子网，多个 SVM
安全性：无
其他考虑因素：无

Triple-O “Under Cloud”

使用 Triple-O 部署 OpenStack 的部署者在 under cloud 层使用 Manila 来启动/关闭存储服务器实例，以促进 Manila 服务扩展/收缩。用于 Cinder 后端或 Glance 存储库的 under cloud 配置原语（例如 NFS 导出）被使用

网络：扁平，单个子网，多个共享服务器
安全性：待定
其他考虑因素：待定

设计变更（第二次迭代）

为了适应上述用例，Manila 需要进行以下变更

驱动模式

我建议每个驱动程序运行在几个预定义的“模式”之一（我不喜欢“模式”这个词，但它解释了这个概念）

单个 SVM
扁平网络多 SVM
分段网络多 SVM（可能带有变体）

每个驱动程序可以支持一个或多个模式，但管理员通过在 conf 文件中指定它来选择使用的模式。如果对同一硬件有意义，可以为不同的模式创建单独的驱动程序。根据选择的模式，管理员还需要在 conf 文件中提供其他详细信息。

单个 SVM

在这种模式下，驱动程序基本上没有任何网络要求。假定由驱动程序管理的实际存储控制器拥有其所需的所有网络接口。Manila 将期望驱动程序直接配置共享资源，而无需事先创建任何“共享服务器”（Manila 可能会想要创建一个虚拟共享服务器）。Manila 将假定通过任何导出共享资源的网络接口都可被所有租户访问。这种模式对应于现有的一些驱动程序已经在做的事情，但它明确了管理员的选择。在这种模式下，共享网络在创建共享资源时实际上不需要，甚至可能被忽略。稍后会详细介绍。

扁平网络多 SVM

这种模式是新的，专门设计用于涵盖现有设计无法很好地解决的中间地带。一些存储控制器可以创建 SVM，但由于物理/逻辑网络的各种限制（如上述用例中概述），所有 SVM 必须位于扁平网络上。在这种模式下，驱动程序需要一些东西来为 SVM 配置 IP 地址，但所有 IP 都来自同一个子网，并且假定该子网本身可被所有租户访问。

具体来说，驱动程序在这种模式下可以期望 Manila 提供

子网定义——网络地址、掩码、广播地址和网关地址
每个共享服务器在创建期间的特定 IP 地址

在这种模式下，共享网络的安全性部分很重要，因为它允许租户指定安全要求，例如 AD/LDAP 域或 Kerberos 领域。共享网络的子网部分实际上没有用处。Manila 必须假定在 SVM 创建的子网中可访问所有引用安全服务的主机，这限制了这种模式有意义的情况。

分段网络多 SVM

这种模式对应于 Manila 当今的主要用例，它增加了对它的形式化和清晰度，并添加了新功能。在这种模式下，假定驱动程序能够创建 SVM 并将其连接到现有的分段网络。目前，我们直接在共享驱动程序中使用共享网络，这会导致一些坏事，例如在通用驱动程序内拥有特定于 Neutron 的代码。我想更清楚地定义驱动程序从 Manila 要求的以及反之亦然，并将这些定义为一个具有多个实现的接口（管理员选择实现）。

至少，驱动程序可以期望 Manila 为每个新的 SVM 提供

子网定义（网络地址、掩码、广播地址和网关）和 IP 地址列表
分段类型：VLAN、VXLAN、GRE、STT 等
分段 ID 和与分段类型相关的任何其他信息

我想指出几点

驱动程序不必支持每种类型的分段。在许多情况下，仅支持 1 种。这个事实应该是明确的，并且 Manila 应该在存在阻抗不匹配时提供有用的错误消息。
目前，每个 Manila 驱动程序决定是直接在租户提供的共享网络中指定的子网上创建 SVM，还是为 SVM 创建一个新的“服务网络”并配置租户子网与服务网络之间的路由。应该将逻辑移动到公共位置，以便驱动程序可以专注于仅创建 SVM，而不必担心网络管道。
我们非常重要的是要删除对 Neutron 的显式依赖，因为我们希望启用 Neutron 不存在但 Neutron 仍然是 Manila 中管理网络的首选机制的用例，并且我们应该尽力避免重新实现 Neutron 中已有的功能。

网络助手

我相信我们需要在 manila-share 服务中定义一个更明确的对象来管理网络操作。不仅仅是之前讨论过的“网络插件”，我建议使用网络助手，它将在 manila.conf 中拥有自己的配置选项。网络助手应支持以下用例

管理单个子网中的地址池。在这种模式下，助手将仅定义一个子网并从该子网配置 IP 地址。实际实现可以基于使用 DHCP 服务器，或引用 Neutron 或 Nova-Net 网络/子网，或者可以纯粹用 Python 代码实现，状态存储在 Manila DB 中。理想情况下，所有 4 种情况都将作为网络助手的插件实现。
管理服务子网。对于分段多 SVM 的情况，管理员可以选择将所有 SVM 放在自己的子网上，并路由租户网络与服务网络之间的流量（有时称为 L3 连接）。这种方法有很多优点，包括减少数据中心的广播域，并允许 VLAN 基子网与 VXLAN 或其他子网混合。如上所述，实际实现可以简单地构建在 Neutron 或 Nova-Net 之上，或者我们可以为此服务提供一个独立的插件。助手需要能够作为此操作的一部分设置路由。
与共享网络交互。如果管理员选择并且驱动程序能够支持，我们应该支持直接在租户的子网上配置 SVM，前提是共享网络提供（有时称为 L2 连接）。此用例的主要优点是能够通过移除路由器来以高带宽/低延迟连接存储到虚拟机。此外，此案例已经得到支持，我们不应该停止对其的支持。

共享网络变更

驱动模式的添加以及对 Neutron 以外的事物支持使我们重新考虑共享网络的用途/价值。显然，它们对于某些用例仍然至关重要，但在其他情况下，它们根本不需要。为了明确起见，我认为管理员需要有设置默认值和防止或允许租户修改它们的方法，并且管理员需要一种方法来告知租户哪些值是必需的。这可能是提案中最棘手的部分（这就是为什么我把它留到最后），因为它会改变面向租户的 API，并且租户的体验会根据管理员的选择而发生巨大变化。

需要考虑的事项

单个 SVM 驱动程序将忽略共享网络的所有内容。使用此模式的管理员可能希望完全禁用共享网络的创建。可能管理员想要创建一个“默认”共享网络，租户可以指定它，但这最终是不必要的，因为它将被忽略。如果允许混合单个 SVM 后端和多 SVM 后端，情况会变得更加复杂，因为在这种情况下，共享网络可能会很重要，具体取决于选择的后端。也许这意味着调度器需要了解后端模式并相应地安排请求。在这种情况下，默认共享网络更有意义，因为它为租户提供了一种可以降落在单个 SVM 后端上的请求的方式。
扁平网络驱动程序将忽略共享网络的子网部分，实际上对于（可能）在防火墙中打孔以允许 SVM 对租户网络提出请求之外的所有目的。但是，租户不需要知道/关心这个事实。从租户的角度来看，共享资源将在“其他”网络上创建，他不知道这是因为选择了扁平网络驱动程序，还是因为网络助手创建了一个新网络并建立了到它的路由（L3 连接）。
分段网络驱动程序将关心共享网络中的子网和安全服务，并且管理员无法为这些值提供合理的默认值。

子网

当前的设计允许通过直接引用 neutron 网络/子网 ID 来指定子网。如果使用 Neutron 的话，这很好，但如果不使用，我们需要提供其他选项。最明显的是也允许使用 Nova-Net ID，用于那些使用 Nova-Network 代替 Neutron 的云环境。此外，对于独立环境，我们必须提供第 3 个选项，该选项不依赖于 Nova 或 Neutron，除此之外我们可以做任何想做的事情。