富国银行首席工程师的建议丨OpenStack管理员如何决定Neutron的网络部署策略？
来自富国银行云网络团队的首席工程师Alain Swanson告诉你，共享的运营商网络可能更适合OpenStack私有云的原因。
以下文章由富国银行云网络团队首席工程师Alain Swanson撰写。
在查看了大量OpenStack网络的现有附属产品后，人们能够迅速得出结论，被广泛接受的网络部署模式将中心放在了租户网络（虚拟网络）上。在本文中，我将讨论在私有云环境下租户网络的问题，或许运营商网络（尤其是共享的运营商网络）可能会更加适合。
什么是租户？
本文中所使用的“租户”（tenant）这一术语能够被当前使用频度很高的术语“项目”（project）替换。在私有云中，指定的租户可能会被映射至一个特定的业务单元、具体的多层应用，甚至是一个单独的应用层。在这些示例中，所有租户最终归属于一个单独的组织。这与公有云形成了鲜明的对比，在这里单独的租户通常代表一个独立的组织。
租户网络/运营商网络是什么？
租户网络与运营商网络之间的主要区别在于谁来配置它们。运营商网络由代表租户的OpenStack管理员创建，它能够专属于一个特定的租户，也可以被一部分租户（参见RBAC（针对网络的基于角色的访问控制），或者被全部租户共享。另一方面，租户网络由租户创建，以便于他们使用自己的实例，（基于默认的策略设置）其不能被共享。
通常，运营商网络在数据中心内直接与物理网络（如VLAN）相连，不需要提交需求申请。首先要使用overlay方式（例如GRE或VxLAN）配置运营商网络，然后通过软件或硬件网关将overlay网络映射至物理网络。同样的，租户网络可以通过底层或是overlay技术实例化。一般情况下，租户并不知道他们的租户网络是如何在物理上被实现的。总之，选择底层或overlay技术通常与使用的是租户网络还是运营商网络并没有关系。
最后，运营商网络依靠的是物理网络基础设施提供默认网关/第一跳路由服务。相反，租户网络是依靠Neutron路由器实现这一功能的。Neutron路由器必须将其上游界面依附于被称为“外部的”运营商网络才能连接物理网络。
▲租户网络
▲共享的运营商网络
网络安全与网络拓扑交织在了一起
以往网络安全只可能被应用在网络的边界，通常使用的是防火墙或路由器。近期，VLAN融合等先进技术已经能够使用所谓的透明防火墙。目前，通过使用与Neutron安全群组连接的Neutron逻辑端口，网络安全可以被直接应用在工作负载所依附的网络中。因此，使用安全群组而非专门的二层网络配置安全区和保护应用层安全如今已经成为了可能。
▲传统的应用层布置
▲使用安全群组的应用层布置/安全区
此外，Neutron端口安全还预防了MAC和IP嗅探等二层攻击技术。
这些Neutron功能让共享的运营商网络在应用层布置/安全区方面，成为了租户网络的一个可行的备选方案。
租户网络IP地址空间选择问题
在配置一个租户网络时，租户必须明确他们希望使用的IP地址空间。租户如何做出正确的选择呢？实际操作起来这是一个比第一眼看上去更为困难的挑战。
让我们可以假设每个源NAT或目标NAT都将被使用，因此租户网络IP地址空间永远无法暴露在云外。即使在这种情况下，租户也无法选择他们希望的任何IP地址（即便是在RFC 1918私有地址空间）。如果租户选择了一个企业在所有地方都在使用的IP地址空间，那么企业网络将无法与租户网络进行通信。
此外，与同一Neutron路由器连接的任何其他租户网络也将无法与企业网络进行通信。这种情况的发生是因为，在OpenStack中产生自外部云的网络流量的源IP地址并不受控于NAT。OpenStack仅将NAT用于产生自租户网络的网络流量的源IP地址。自从10.10.10.0/24网络被直接与Neutron路由器和租户网络中的实例连接，从云至企业网络的流量将无法找到自己的路径。
▲使用源NAT时IP地址空间冲突示例
如果租户使用针对其网络的私有地址空间（云消费者全部来自注册的地址空间），那么这种情况在公有云中将不会出现。在私有云环境中，使用的是私有地址空间，云的消费者则来自私有地址空间。
值得感谢的是，OpenStack Kilo版本中引入了子网池作为一个处理租户网络IP地址空间选择问题的机制。不幸的是，支持子网池的Horizon增强功能直到Liberty版本才被提供。即便如此，子网池设定为大块的地址空间能够委托给云。
IPv4地址空间出现不足
在大型组织中，即使RFC 1918私有地址空间也是稀缺的东西，因而必须被谨慎分配。常识表明，共享资源比专用资源拥有更高的利用率。当我们将专用租户网络的IP地址空间利用率与共享的运营商网进行对比后，这一看法显然是正确的。在租户网络中地址空间的“能力”可能会被闲置，而共享的运营商网络将会充分发挥它们的潜力。
网络地址转换（NAT）——如果需要就使用它们
默认情况下，当Neutron路由器附属于外部运营商网络时，源NAT（本质上是端口地址转换）是可以使用的。当使用由外部运营商网络分配的浮动IP地址时，依据每个实例基础可视情况使用目标NAT。需要重点指出的是，当使用NAT时，某些协议可能会出现问题。RFC 3027已经详细列出了一些这类示例，RFC 2993也对NAT的架构含义进行了阐述。实际上，NAT违反了端到端规则，终端系统应该管理状态，网络应该是一个简单的数据报服务。NAT在特定使用情况下肯定会被用到，但是它们应该被尽可能地避免。
此外，某些企业可能会要求所有联网系统应该具有可达性，所有实例必须要能够从云外部访问。这意味着每个实例与NAT的比例为1:1，或是在逻辑上省去NAT。
当将Neutron路由器附加到外部运营商网络时，租户可以选择完全禁止NAT。然而这将会带来租户网络的可达性问题。我们将在下面详细讨论这一问题。
租户网络的可达性
当使用源NAT或目标NAT时，实例会使用外部运营商网络的IP地址与云外部的系统进行通信。与外部运营商网络相关的子网将成为早期运营商网络部署程序中的一部分。因此实例能够与云外部的系统进行通信。
如果NAT被禁用，那么与租户网络相关的IP地址空间将直接暴露给云外部的系统。如果部署了多个Neutron路由器，物理网络路由器基础设施将如何知道哪个IP地址位于特定Neutron路由器之后呢？OpenStack Neutron目前还不支持任何动态路由协议，因此目前还不可能以程序方式将租户网络作为租户网络创建程序的一部分。为了让租户网络对外部系统具有可达性，必须要设计一个OpenStack带外方案。
尽管远未及路由的租户网络拓扑那样普及，租户网络也能够被隔离。在这种情况下，由租户创建的二层网络将无法享受通过Neutron路由器与外部世界的连接，但是可通过双宿主机等跳板主机实现访问。
Neutron路由器的依赖性
租户网络依靠Neutron路由器与其他网络相联。这也意味着租户网络受限于Neutron路由器所支持的功能。如果一个租户需要IP多播路由，那么这将成为一个问题。相反，由于运营商网络依靠物理网络基础设施提供三层服务，实例将有可能获得一套更具活力的功能。
对未来和IPv6的展望
IPv6解决了以上提及的一些顾虑。主要是IPv6目前不会出现地址空间不足的问题。同样的，将大段的IPv6地址空间分配给子网池可以消除租户网络IP地址空间选择的问题。由于不再需要保留地址空间，所有的网络都能够被分配至一个唯一的、且可路由的IPv6地址空间，因而NAT也不再被需要。
尽管如此，问题依然存在。如果应用分层布置/安全区能够通过Neutron安全群组实现，以及MAC/IP嗅探可通过Neutron端口安全防范，那么是否还需要专用的二层网络呢？
运营商网络的优势
运营商网络是OpenStack管理员为租户使用预先创建的，其将租户从配置网络、选择合适的地址空间、确保它们具有可达性的责任（负担）中解放了出来。共享的运营商网络可以更为高效地利用稀缺的IPv4地址空间。应用分层布置/安全区不再需要部署专用的二层网络，并且可以通过通用的共享运营商网络中的安全群组实现。最后，如果专用的二层网络被托管，那么专用的运营商网络也能够被配置。
结论
OpenStack管理员必须要决定他们的Neutron网络部署策略——是选择租户网络或是运营商网络，还是将两者有机地结合起来。许多现有的文档都将重点放在了对租户网络的部署和管理方面。运营商网络似乎受到了忽视。尤其是在私有云环境中，鉴于租户网络所面临的挑战，以及运营商网络所具有的相应优势，我们应该认真考虑一下运营商网络。