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

运维 系统运维 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已经很广泛的应用了,例如我们每天用到的VPN协议,如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天后,才能转载本文。尊重知识,请必须全文转载,并包括本行及如下二维码。

责任编辑:火凤凰 来源: 高效运维
相关推荐

2014-08-06 09:11:52

OpenStack

2015-10-13 11:08:41

2015-07-09 10:22:27

CloudStackOpenStack云计算

2014-08-26 11:08:50

OpenStack运维

2020-04-17 13:35:15

OpenStack私有云云计算

2015-06-10 14:37:09

网易私有云OpenStack

2014-08-06 09:39:27

OpenStack

2014-11-27 10:07:43

IT运维

2018-07-31 14:40:00

架构

2018-11-26 15:07:39

OpenStackZStack存储

2016-01-20 11:22:17

增量部署全量部署运维

2015-08-05 13:25:04

网络运维

2012-07-03 11:18:20

运维disable tab

2021-09-03 08:44:02

运维安全身份认证堡垒机

2010-01-21 22:19:25

网络优化运维管理摩卡软件

2015-08-27 09:35:29

OpenStack运维指南VLAN

2013-01-11 15:42:40

IT运维云计算

2017-02-24 21:10:47

虚拟化

2020-03-11 08:04:38

反脆弱运维云时代

2015-06-01 11:10:24

点赞
收藏

51CTO技术栈公众号