[译] OpenStack Kilo 版本中 Neutron 的新变化
本帖最后由 不会飞的小凯凯 于 2015-12-11 15:38 编辑问题导读:
1.Neutron的核心插件是什么？
2.Neutron安全组件有什么作用？
3.Neutron的高级服务有哪些？
static/image/hrline/4.gif
OpenStack Kilo 版本，OpenStack 这个开源项目的第11个版本，已经于2015年4月正式发布了。现在是个合适的时间来看看这个版本中Neutron到底发生了哪些变化了，以及引入了哪些新的关键功能。
1. 扩展 Neutron 开发社区 (Scaling the Neutron development community)为了更好地扩展 Neutron 开发社区的规模，我们在Kilo开发周期中主要做了两项工作：解耦核心插件以及分离高级服务。这些变化不会直接影响 OpenStack 用户，但是我们期望这些工作会带来代码量的减少，以及新功能开发速度的提升，从而最终带来创新的加速。下面我们来一项一项的来看。
1.1 解耦Neutorn核心插件 (Neutron core plugin decomposition)从设计上看，Neutron 采用可插拔式（pluggable）架构，这种架构允许实现 Neutron API 的可定制后端。Neutron 核心插件（core plugin）是整个Neutron项目开发的核心部分，它就像在逻辑API层和实际实现层之间的一个粘合层（glue）。随着Neutron项目的演进，越爱越多的插件被引入了，它们来自各个不同的开源项目和社区（比如 Open vSwitch 和 OpenDaylight），以及广大供应商（vendor，比如 Cisco, Nuage, Midokura 等等）。在Kilo 开发周期的一开始，Neutron 有十几个插件和驱动，包括核心插件（core plugins）、ML2 机制驱动（mechanism drivers）、L3 服务插件，以及 L4-L7 插件比如 FWaaS、LBaaS 和 VPNaaS 等，其中大部分插件的代码都直接放在Neutron项目代码库中。 因此，需要检视的Neutron代码的数量，包括所有这些插件和驱动的代码，已经增长到了导致项目开发规模无法再增长的程度。让不熟悉这些驱动或者插件的代码检视者，以及没有合适的硬件或者软件环境来验证这些插件和驱动代码的代码检视者来检视这些插件和驱动的代码是不现实的。同时，当供应商提交的代码不能及时地被合并时，这些供应商难免会失望。要改善这种境况要做的第一件事情是，将Neutron 核心插件和ML2驱动的代码从 Neutron 代码库中解耦。具体的做法是，只在Neutorn代码树中给上文提到的每个插件和驱动保留一个薄薄的代理（ shim/proxy）层，再把它们所有的后端实现逻辑移到不同的代码库中，新的代码库的一个比较自然的选择是 StackForge。这么做的好处是显而易见的：Neutron 代码检视人员可以把主要精力放在检视Neutron 核心代码上，同时厂商和插件的维护者可以按照他们自己的迭代周期做迭代。社区已经鼓励各代码提供者去立即着手这项解耦工作，但是也不强制要求所有的插件在Kilo版本发布前完成所有工作，这主要是为了给各厂商留下足够的时间。关于该流程的更多信息，请阅读该文档，它是专门用来跟踪所有插件的进度的。
1.2 分离高级服务 （Advanced services split）上述的第一件事情只是着眼于Neutron 核心插件和 ML2 驱动，一个并行的工作是对L4-L7 高级服务(FWaaS, LBaaS, and VPNaaS)做同样的事情。和核心插件类似，这些高级服务之前也是将代码存放在Neutron主代码库中，一个相似的后果是导致Neutron 核心代码检视人员失去专注性。从Kilo开始，这些服务的代码将会被分离到它们各自的代码树中。因此，现在Neutron 有四个不同的代码库：一个用于基础的L2/L3 网络、分别有一个用于FWaaS, LBaaS, 和 VPNaaS。因为目前高级服务插件还比较少，目前各厂商和插件的代码还会被保留在各个服务的代码库中。值得一提的是，这么做不会影响到OpenStack 用户。这些服务即使现在被分离出去了，它们的 API 或者CLI 不会有任何变化，它们还会和之前一样使用相同的 Neutron 客户端。同时，我们确实能预计到，由于每个高级服务都有从Neutron分离出去成为独立组件的潜力，目前所做的分离工作确实为它们将来更深层次的变化打下了基础，将来它们可能会提供它们自己的 REST 端点、配置文件和CLI/API 客户端。这也使得它们的开发团队能专注于一个或者几个高级服务从而有可能实现更大的变化。
2. ML2/Open vSwitch 端口安全 （ML2/Open vSwitch port-security）安全组（Security-groups）是Neutron 最常用的功能之一，它允许租户去指定允许经过一个Neutron 端口的网络流量的类型和方向（进/出），从而可以高效地为虚机创建防火墙。
从安全考虑，Neutron 安全组的实现，总是会自动创建阻止IP 地址欺骗攻击的规则，来避免虚机收到或者发出与虚机的Neutron 端口的 MAC 或者 IP 地址不符的网络包。当大多数用户认为安全组和防IP欺骗规则非常有用而且必要时，一些人要求增加开关选项来使得他们可以在特定端口上不创建这种规则。有这种需求的主要用例是当在虚机上运行网络服务的时候，一个常用的例子是 NFV。考虑一个在 OpenStack 虚机中部署路由应用的例子：它需要能够接收不是发给它自己的包，还需要能够发出不是从它任何端口产生的包。当使用了安全组时，这个虚机是没法做这些事情的。
我们来看看这个例子的拓扑图：Host 1 是一个虚机，它的IPv4 地址是 192.168.0.1，现在它需要访问 Host 2，它的IP地址是 172.16.0.1。这两个主机通过两个运行路由应用的虚机（R1 和 R2）连接在一起，这两个虚机分别被配置为主机1 和 2的缺省路由。上图显示了端口的默认IP地址。我们来看看Host 1 是如何向 Host 2 发包的：
[*]Host 1 产生一个 IPv4 网络包，源IP是 192.168.0.1，目的 IP 是 172.16.0.1。因为两个虚机在不同网段上，R1 使用它自己的MAC地址来响应Host 1 的 ARP 请求，因此，Host 1 产生的网络帧的目的 MAC 地址为 3B-2D-B9-9B-34-40 。
[*]R1 收到该包。注意这个包的目的IP 是 172.16.0.1，不是R1自己。在 R1 的端口上应用了Neutron安全组以后，防IP欺骗规则就默认被应用了，这个包就会被丢弃，因此 R1 无法完成进一步的路由。
Kilo 版本之前，你对整个云要么禁止安全组要么使用安全组。从 Kilo 版本开始，可以使用新的属性 port-security-enabled 来启用或者禁用某个端口上的安全组了。这个新的属性目前被 Open vSwitch agent 和 IptablesFirewallDriver 支持。回到之前的拓扑，现在可以在 R1 和 R2 的端口上禁用安全组了，同时在主机虚机的端口上使用安全组。这么做以后，就可以正常地做路由了。更多的信息，以及配置示例，可以在 Red Hat 公司 Terry Wilson 的blog上找到。
3. IPv6 增强 （IPv6 enhancements）随着Juno版本中引入的一些新的功能，包括允许使用 SLAAC 和 DHCPv6 来向租户网络分配IP地址，以及支持由外部路由器产生的广告给物理网络的 RAs消息等，IPv6 已经成为 Neutron 一个新的焦点领域 。Kilo 版本中 IPv6 功能在进一步地成熟，因此也带来了一些其它方面的增强，包括：
[*]允许给一个网络分配多个IPv6 前缀
IPv6 允许给一个网卡分配多个IP前缀。这其实是个常见的配置，通 常地，所有的网卡会被分配一个本地连接地址（link-local address， LLA）用于处理本地连接的网络流量，其中一个或者多个网卡会被分配全局单播地址（ global unicast addresses ，GUA）来处理端到端的网络连接流量。从 Kilo 版本开始，用户可以分配多个IPv6 子网给一个网络。当子网的类型是 SLAAC 或者 无状态的DHCPv6的时候，一个Neutron 端口会被从每个子网中分配一个IPv6 地址。
[*]更好的IPv6 路由支持
Kilo 版本中，OpenStack IPv6 没有网络地址转换（NAT - network address translation ）或者 浮动IP。这是假设虚机会被分配全局可路由地址（globally routed addresses ）因此能够和纯L3路由通信的。Neutron中的 neutron-l3-agent 组件通过创建和维护虚机路由器来负责Neutorn 内的路由。要在虚机路由器中支持IPv6， 需要以下的两个功能： 1.子网之间的路由：这是指网络包在同一租户的不同IPv6 子网之间的路由。因为这些网络流量是在OpenStack云内部被路由的，它们不会离开OpenStack云去任何外部系统，这种路由往往被称为“东西”路由。这个功能在Juno版本中就支持了，而在Kilo 中没有大的变化。 2.外部路由：这是指在IPv6租户子网和IPv6 外部子网之间的路由。因为这些流量需要离开Neutron网络去外部网络，它们往往被称为“南北”流量。因为没有 IPv6 NAT 支持，虚机路由器（virtual router）只需要简单地在内部子网和外部子网之间做路由。这个功能在Juno版本就支持了，但是在Kilo 中，针对运维人员（operator）创建外部网络的方式做了主要的优化，现在他们不需要给外部网络创建Neutron子网了。Meutron虚拟路由器可以自动地通过SLAAC 学习得到默认网关的信息（如果RAs 在上行路由器上被启用了的话），或者由运维人员使用 l3-agent 配置文件中新的 ipv6-gateway 配置项来手动地指定默认网关。
[*]增加若干DHCP选项
使用 Neutron，用户可以指定子网额外的 DHCP 选项。这主要用于给 Neutron 端口分配诸于 DNS 或者 MTU 这样的附加信息。一开始，这些配置只能用在端口的 DHCPv4 或者 DHCPv6 地址上，它的问题是当给一个端口同时分配了IPv4 和 IPv6 两个地址时无法使用。
从 Kilo 版本开始，可以为 DHCPv4 和 DHCPv6 设置额外的DHCP 选项。Neutron 创建和更新端口（port）的 API 增加了一个新的参数 “ip_version”，它会指定某个给定 DHCP 选项的IP版本（4 或者 6）。
4. LBaaS v2 APILBaaS 是 Neutron 高级服务之一。它允许租户按需创建负载均衡器，后端使用一个基于不同负载均衡技术的开源或者闭源的服务插件。在Red Hat Enterprise Linux OpenStack Platform上的开源方案是基于HAProxy的。LBaaS v1.0 API 包括基本的负载均衡能力，实现了一个简单而直接的工作流来设置负载均衡服务：
[*]创建一个池
[*]为池创建一个或者多个成员
[*]创建健康状态监控器
[*]创建一个和池关联的虚机IP
这个实现在做初始实现和部署LBaaS时会有帮助，但是，它不足以提供企业级的高级负载均衡器。LBaaS 2.0 能够提供更加强大的负载均衡方案，包括支持SSL/TLS 端点。要实现这个目标，需要重新设计LBaaS的架构，具体你可以参考HAProxy reference plugin.
5. 增加 DVR 对 VLAN 模式的支持 (Distributed Virtual Routing (DVR) VLAN support)DVR，在 Juno 版本中被首次引入，允许跨计算节点部署 Neutron 虚拟路由器，这样每个计算节点就能够为它上面运行的虚机提供路由服务。这会提高虚拟路由器的性能和可扩展性，被视为实现更高效的L3网络的一个重要里程碑。提醒一下，默认的OpenStack Neutron架构中，使用了一个专用网络节点集群来处理云中的大部分网络服务，包括 DHCP，L3 路由和 NAT。这意味着从计算节点上发出的网络流量需要经过网络节点才能被正确地路由。通过使用 DVR，计算节点就能够处理它本地虚机在网段之间（东西）的路由以及浮动IP 的NAT。DVR 任然依赖专用网络节点来提供默认的 SNAT 服务，来允许虚机访问外部网络。Kilo 之前，DVR 只支持使用隧道网络包括 GRE 和 VXLAN 等来做租户网络隔离。这样的话，它就阻碍了用户就使用 VLAN 租户网络了。在Kilo 中，DVR 增加了VLAN 的支持，因此，现在 DVR 即可以支持隧道网络也可以支持VLAN 了。更多的关于DVR的信息，强烈建议你去读 Red Hat 公司的 Assaf Muller 的三篇非常棒的blog：overview and east/west routing, SNAT, and Floating IPs：。
6. 查看HA虚拟路由器的状态 (View the state of Highly Available routers)Juno 版本中引入的一个重要功能是L3 HA 方案，它允许在多个网络节点上设置 active/active HA 模式的 neutron-l3-agent。这个方案基于 keepalived，内部使用 VRRP 协议来组建高可靠的虚拟路由器组。根据设计，每个组只有一个活动的路由器负责网络转发，以及一个或者多个备用路由器，它们在等待活动路由器失效时接替它成为新的活动路由器。主/备路由器是被随机地部署到不同的网络节点上的，因此负载会在这些节点上被分摊。基于 Juno 方案的一个限制是，Neutron 没法报告 HA 路由器的状态，这会给问题定位和维护带来困难。Kilo 版本中，运维人员可以运行 neutron l3-agent-list-hosting-router <router_id> 命令来查看活动的路由器在那个网络节点上。
7. 允许选择浮动IP (Ability to choose a specific floating IP)浮动IP 是被动态地分配给虚机的IPv 4 地址，有了它以后，虚机可以被从外网中访问，比如常见的因特网。一开始，当给虚机分配浮动IP的时候，IP 地址是随机地从地址池中选取的，因此无法保证一个虚机在多次分配时会被分配到同样的地址。从Kilo 版本开始，用户通过使用新的 floating_ip_address API 参数，可以指定特定的浮动IP地址来分给某个虚机。
8. MTU 广播功能 (MTU advertisement functionality)这个新的功能允许配置一个网络的（期望）MTU，并且发布到客户机操作系统中。这个新功能能够避免多个网络中的MTU不一致，因为这种不一致会带来一些不可预测的后果，比如网络连接问题、丢包和网络性能降低。
9.提升性能和稳定性(Improved performance and stability)OpenStack 网络社区一直致力于提供一个更稳定的和代码更成熟的 Neutron。在 Kilo 提供的众多性能和稳定性优化改进中，我想着重强调两个：直接使用 OVSDB 和 ML2/OVS 插件通信，而不是使用 OVS 的 ovs-vsctl 命令；广泛地重构 l3-agent 的代码。尽管这两个改进都没有给用户引入新的功能，但是它们确实是社区一直在为优化Neutorn代码而努力的一个代表，特别是核心的L2 和 L3 组件，它们对所有的负载都非常关键。
10. 展望Liberty 版本 (Looking ahead to Liberty)Liberty，下一个 OpenStack 版本，计划于 2015年10月15日发布。我们正在紧张地为 Vancouver 设计峰会做准备，到时新功能和改进提议都会被讨论到。你可以查看 Neutron specifications for Liberty页面来跟踪哪些提议会被接受到 Neutron 中，哪些会在Liberty 版本中得以实现。
原文： What’s Coming in OpenStack Networking for the Kilo Release，Posted on: May 11, 2015，by Nir Yechiel
页:
[1]