Manila/Networking

Manila

这是一篇关于 Manila（OpenStack 共享文件系统）的网络配置文档。

选项概述

在 OpenStack 和 Manila 中创建网络配置有很多选择。以下是一些管理员需要做出的选择示例，以及这些选择可能产生的影响。

L2 与 L3 连接

• L2 - 共享服务器的网络接口创建在租户拥有的子网中
  • 同一子网中的虚拟机可以直接访问存储
  • 需要设置网络分段（VLAN、VXLAN）
  • 需要能够为每个租户创建共享服务器的驱动程序
  • 广播域可能会跨机架或整个数据中心
• L3 - 共享服务器只能通过路由器访问
  • 适用于任何驱动程序
  • 适用于不支持 SVM/共享服务器概念的控制器
  • 限制广播域
  • 需要虚拟或物理路由器
  • 为了创建共享服务器，Manila 需要从现有子网获取 IP 地址，并且在某些情况下创建新的子网/路由器

共享服务器

• 每个租户创建一个
  • 私有网络
    • 安全性最高
    • 适用于通用驱动程序和一些基于硬件的驱动程序
  • 公有网络
    • 仍然提供高级别的安全性
    • 适应不理解 VLAN/VXLAN 的存储控制器
    • 适应开发人员无法控制的物理交换机的实验室配置
• 通用
  • 安全性由存储控制器而不是网络强制执行
  • Manila 不需要管理任何网络资源

网络管理

• Neutron
  • 功能最强大，功能众多：flat、VLAN、VXLAN、GRE 等
  • 未被最终用户广泛部署
  • Manila 项目最初就是从这里开始的
• Nova-net
  • 支持 flat 和基于 VLAN 的网络
  • 广泛使用
• 其他插件
  • 最大程度地减少对外部组件的依赖
  • 简单的插件，用于开发/测试，不用于生产
  • 可能存在最终用户自定义插件

计划

我们的总体目标是为管理员提供灵活性，以便他们可以在任何环境中都使用 Manila，无论他们做出了什么其他选择。权衡在于如何在不让管理员感到过于复杂的情况下做到这一点。

对于 Icehouse 和 Juno，我们坚持了一组相对狭窄的选项：仅 Neutron，始终为每个租户创建一个共享服务器，并优先选择 L2 网络而不是 L3 网络。之所以做出这些选择，是因为它们提供了最大的安全性，并且在公共云类型的环境中表现良好。

我们面临的问题是，开发人员通常无法在他们的开发实验室中重现公共云中复杂的网络配置，并且希望尝试 Manila 的用户在设置基本的配置方面面临着很高的门槛。

对于 Kilo，我们需要扩展选项集，以使开发人员的生活更轻松，并使简单的概念验证风格的部署更容易实现。