|
|
51CTO旗下网站
|
|
移动端

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

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

作者:闫国旗来源:高效运维|2015-08-21 09:32

嘉宾介绍

闫国旗,就职于京东集团,任资深系统架构师,主要负责京东集团的基础服务建设,专注于数据库、分布式计算、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天后,才能转载本文。尊重知识,请必须全文转载,并包括本行及如下二维码。

【编辑推荐】

  1. OpenStack开源新势力能否撼动VMware帝国?
  2. 干货:基于网易的OpenStack部署运维实战
  3. 京东技术开放日第四期—电商推荐搜索系统架构与算法实战
  4. Ubuntu 15.04 发布 支持OpenStack Kilo和LXD Hypervisor
  5. Google加入OpenStack基金会,向容器技术迈进
【责任编辑:火凤凰 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

读 书 +更多

非常网管——网络工程案例

本书面向企业网络应用需求,详细介绍了Windows网络互联解决方案、中小企业共享上网解决方案、基于ISA Server 2006的代理服务器与防火墙解决...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊