部署Openstack，网络运维中的组件该如何选择？

作者：闫国旗 2015-08-21 09:32:15

运维

系统运维

OpenStack 在Openstack中网络组件的选择，一定要明确你的业务场景。新版本Neturon有很多诱人的特性，但一定要经过严格的测试，才可应用。网络无小事，做网络规划和设计时一定要贴合你的业务，尽量做到简单高效。 

　　嘉宾介绍

　　闫国旗，就职于京东集团，任资深系统架构师，主要负责京东集团的基础服务建设，专注于数据库、分布式计算、SDN、网络安全等技术领域。

　　先简单介绍一下Nova-Network和Neutron。

　　Nova-Network

　　Nova-Network是Openstack在Folsom版本之前的网络解决方案，做为Compute项目(Nova)的子模块之一。支持Flat Network，Flat DHCP Network，VLAN Network等网络模型，利用到的主要技术有linux-bridge，vlan等。

　　Neturon

　　Neturon是Openstack的Folsom版本正式发布的，将网络模块从Compute中剥离出来，独立发展。其实在Essex版本就已经提供了试用，在Grizzly版本得到了一定的增强。

　　在Havana版本之后，由于商标问题从Quantum更名为Neturon。支持Local Network，VLAN Network，GRE Network，VXLAN Network等网络模型。利用到的主要技术有linux-bridge，ovs，vxlan，gre，vlan，openflow等。

　　目前Openstack已经Release了Kilo版本，Neturon在经历了7个大版本后，已经做了相当多的改善。Neturon本质上就是Nova-Network后续的升级版本。

　　Nova-Network的网络模式相对较为简单，Flat和FlatDHCP都是通过统一的IP池，对VM进行IP分配，不同的是IP分配的手段。

　　该两种模式没有实现任何隔离功能，在此类场景下仅能通过安全组等手段进行网络层面的隔离，适合规模较小，网络拓扑不经常变化，且对网络隔离不严格要求的场景。

　　VLAN模式需要在网络设备进行VLAN配置，管理维护成本相对较高，且规模受VLANID宽度的限制，适合有一定隔离需求，但规模较小的场景。

　　在Neturon的实现中，包括：

　　1.控制节点

　　控制节点运行Neturon Server，早期仅仅是用于维护数据库中网络相关的信息。

　　2.网络节点

　　网络节点运行L3 Agent。在DVR模式下，计算节点和网络节点分别要运行L3 Agent和L3 NAT Agent。

　　3.计算节点

　　计算节点和网络节点根据所选择的配置，还要运行相应的Plugin Agent。

　　我们从东西流量和南北流量这两个维度来看Neturon中的网络流向，在Neturon早期没有DVR功能的时候，无论南北流量还是东西流量，在网络路径上都要通过网络节点进行转发，显而易见网络节点成为了最严重的瓶颈，一旦网络节点失效，其所覆盖的网络便瘫痪。

　　DVR的实现，一定程度上降低了网络节点的压力，东西流量及部分南北流量(拥有Floating IP的VM)不再经过网络节点，但网络节点仍然存在瓶颈。

　　Dragonflow在网络节点上运行Openflow控制器，对L3流量进行调度，不再需要L3 Agent。

　　回到这个问题的核心“高可用”上，这里首要解决的问题便是网络节点的高可用，目前主流有以下几种方法：

　　1.替换网络节点

　　Openstack最大的优势就是开放，插件化设计，因此可以很容易将自己原有的产品集成进去。用成熟的硬件方案加上对应的插件，将网络节点替换掉，现在很多厂商都已提供了成熟的解决方案。

　　2.网络节点主从模式

　　在开启DVR功能后，网络节点主要的流量便是SNAT，通过VRRP和Conntrack Table同步，可以实现网络节点的主备。目前社区的实现还不稳定，如果需要的话只能自行实现。

　　3.合并网络节点

　　将网络节点迁移至计算节点，把NAT功能在计算节点上实现，以此降低网络节点失效的故障域。该解决方案需要进行大量的改造，还要消耗一定的计算能力用于网络转发，且维护管理成本较高。

　　4.利用SDN

　　利用Openflow等协议的特性和相关实现，根据数据库定义的网络信息，对数据包包头直接修改并路由，以此实现NAT、LB等网络功能，便不在需要网络节点对流量进行转发，网络节点上的其他功能也需要重新设计实现。

　　除了网络节点是较为明显的瓶颈，另一个我们再聊聊关于Overlay Network。

　　Overlay Network

　　其实Overlay Network已经很广泛的应用了，例如我们每天用到的科学协议，如PPTP，L2TP，MPLS，GRE等。

　　在IaaS这个场景中，常见的隧道协议有以下几种，VxLAN，NVGRE，GRE，Geneva，STT。

　　但GRE属于L3oL3，且性能较差，使用较少，其他几种都是L2oL3。

　　NVGRE和STT主要应用于Microsfot，VMware生态的产品上。

　　Geneva协议在kernel 3.18才提供，因此现在使用最多的便是VxLAN。

　　VxLAN底层使用UDP协议进行承载，而传统网络对UDP的优化较少，特别是在封包解包里需要一定的计算资源，现在采用较多的优化方案是将这一部分计算迁移至硬件上。目前Mellanox的网卡已经支持了VxLAN Offload，Intel最新的网卡也将支持这个新特性。

　　所以在Openstack中网络组件的选择，一定要明确你的业务场景。新版本Neturon有很多诱人的特性，但一定要经过严格的测试，才可应用。

　　网络无小事，做网络规划和设计时一定要贴合你的业务，尽量做到简单高效。 

　　精彩互动

　　1.京东采用的哪种方式?目前私有云vlan其实最合适了吧?

　　目前京东私有云和公有云所面向的业务场景不同,所以网络模型上的选择也有所不同。

　　2.可以把流量直接引导物理交换上吗?

　　目前新部署的机房节点都是接入万兆，现在的网络方案基本都是硬软分离。硬件网络只需要保证基础网络的正常转发即可。

　　3.Cinder后端存储目前你们觉得可以生产使用的有哪个?GlusterFS CEPH?

　　京东的后端存储并没有用社区的方案,而是自行研发。而且这也引出了另外一个问题，在基于云的架构中，块存储真的很有必要吗?

　　可能大家更多的还是保留了传统的业务部署的习惯。

　　4.云平台主要用于京东哪些业务?

　　京东私有云主要支撑整个京东集团的内部业务，京东公有云主要支撑京东生态的相关业务。

　　如何一起愉快地发展

　　“高效运维”公众号(如下二维码)值得您的关注，作为高效运维系列微信群的唯一官方公众号，每周发表多篇干货满满的原创好文：来自于系列群的讨论精华、运维讲坛线上/线下活动精彩分享及部分群友原创。“高效运维”也是互联网专栏《高效运维最佳实践》及运维2.0官方公众号。

　　提示：目前高效运维两个微信主群仅有少量珍贵席位，如您愿意，可添加萧田国个人微信号 xiaotianguo 为好友，进行申请;或申请加入我们技术交流群(技术讨论为主，没有主群那么多规矩，更热闹)。

　　重要提示：除非事先获得授权，请在本公众号发布2天后，才能转载本文。尊重知识，请必须全文转载，并包括本行及如下二维码。