标签：bsp sel log tac 实例化 neutron 无法 provider space
OpenStack的Neutron定义了两种主要类型的网络——Tenant网络和Provider网络。OpenStack管理员必须决定他们的Neutron网络部署策略将如何使用——Tenant网络、Provider网络或两者的某种组合。
本节将描述Tenant网络在私有云环境中所提出的独特挑战，并将为为什么shared Provider网络为企业私有云提供最佳的Neutron网络部署策略而提出一个论证。本节还将讨论网络的断言背后的基本原理。
在本文中，我将特别指出，在私有云环境中，Tenant网络是有问题的，而Provider网络(特别是共享的Provider网络)可能更适合。
在私有云中，租户可以映射到特定的业务单元、特定的多层应用程序甚至单个应用程序层。所有租户最终都属于单个组织。这与公共云形成了鲜明的对比，在公共云中，个体租户通常代表不同的组织。
Tenant网络和Provider网络之间的主要区别在于谁提供了这些服务。Provider网络是由OpenStack管理员代表租户创建的，可以专用于特定的租户，由租户独享或由所有租户共享。另一方面，租户网络是由具体租户创建的，供他们的实例使用，不能共享(基于默认的策略设置)。
通常，Provider网络与数据中心中的物理网络(即虚拟LAN(VLAN))直接相关，但也有特殊的情况。当然，可以使用overlay协议(例如通用路由封装(GRE)或虚拟可扩展LAN)提供一个Provider网络，然后使用软件或硬件网关将overlay网络映射到物理网络。同样，Tenant网络可以使用底层或覆盖技术进行实例化。一般来说，租户不知道他们的Tenant网络是如何实现的。总而言之，对一个underlay or overlay技术的选择通常不影响Tenant网络或Provider网络是否可用。
最后，Provider网络依赖于物理网络基础设施来提供缺省的网关/第一跳路由服务。相反，租户网络依赖于Neutron路由器来实现。Neutron路由器必须把它们的上游接口连接到被指定为“外部”的提供者网络，以便连接到物理网络。
从历史上看，只有在网络的边界(第三层边界)应用网络安全，通常是使用防火墙或路由器。最近，诸如VLAN这样的高级技术已经启用了所谓的透明防火墙。现在，使用Neutron逻辑端口与Neutron安全组一起使用，网络安全可以直接应用于每个工作负载连接到网络的地方。因此，现在可以使用安全组而不是专用的层2网络来保护安全区域，并保护应用程序层。
此外，Neutron的端口安全防止了第2层攻击技术，如MAC和IP欺骗。
总之，这些Neutron特性使共享Provider网络成为应用程序/安全区域的Tenant网络的可行替代方案。
在使用租户网络时，租户必须指定他们希望使用的IP地址空间。租户如何做出适当的选择? 这是一个比乍看起来更困难的挑战。让我们假设任何源NAT或目的地NAT都将被使用，因此租户网络IP地址空间将永远不会被暴露在云之外。
即使在这种情况下，租户也不能选择他们希望的任何IP地址空间(即使是在RFC 1918私有地址空间中)。如果租户选择在企业中其他地方使用的IP地址空间(例如10.10.10.0/24)，那么企业网络将无法与Tenant网络进行通信。此外，连接到同一Neutron路由器的任何其他Tenant网络也无法与企业网络进行通信。这是因为来自于云外的网络流量的源IP地址不受OpenStack的NAT的影响。OpenStack只会将NAT应用到源自于Tenant网络的网络流量的源IP地址。由于10.10.10.0/24网络直接连接到Neutron路由器和Tenant网络上的实例，因此来自于企业网络的云的流量将永远无法在那里找到它的路径。
如果租户为自己的网络使用私有地址空间(因为云的用户都来自已注册的地址空间)，那么这种场景就不会出现在公共云中。然而，在私有云环境中，私有地址空间很有可能被使用，并且有来自私有地址空间的云的消费者。
幸运的是，在kilo版本中引入了子网池作为处理租户网络IP地址空间选择问题的一种机制。不幸的是，直到自由发布之前，对子网池的支持才得以实现。
【Neutron】Tenant Networks vs. Provider Networks
标签：bsp sel log tac 实例化 neutron 无法 provider space
原文地址：http://www.cnblogs.com/howardgoogle/p/7345338.html
