当前位置: 首页 > OpenStack > 正文

用最精炼语言介绍OpenStack网络代码演进的前世今生

用最精炼语言介绍 OpenStack 网络代码演进的前世今生

此文发布时间:2013-9-5 请注意时效性。
时至今日 Neutron 应该已经有了非常大的变化。对于理清 Neutron 的演进还是很有帮助的。

在OpenStack世界中,网络组件最初叫nova-network,它混迹于计算节点nova的代码库中。nova-network可以单独部 署在一台机器上,为了高性能HA也可以和nova-compute一样部署在计算节点上(这也就是所谓的multi-host功能)。

nova-network实现简单,bug少,但性能可不弱哦,直接采用基于Linux内核的Linux网桥少了很多层抽象应该算强大的。不足之处是支持的插件少 (只支持Linux网桥),支持的网络拓扑少(只支持flat, vlan)。

为了支持更多的插件,支持更多的网络拓扑,更灵活的与 nova 交互,于是有了 quantum 工程。quantum 插件不仅支持 Linux 网桥,也支持 OpenvSwitch,一些 SDN 的插件以及其他商业公司的插件。在网络拓扑上,除了支持 flat,vlan 外,还支持 gre, vxlan。但 quantum 不支持关键的 multi-host 特性。

quantum 因为和一家公司的名称冲突,于是,改名为neutron。

neutron 继续演进,quantum 之前的实现存在这么一个问题。我们说道说道。在 quantum 中,实现一种类型的插件一般包括两个部分,一部分与数据库 db 打交道称之为 plugin,一部分是调用具体的网络设备真正干活的称之为 agent。

像 plugin 就有 linux bridge plugin, opevswitch plugin, hyper-v plugin等,这些plugin因为都是与db打交道,变化的字段并不多,所以代码绝大部分是重复的。这样也就出来了一个公共的 plugin 叫 ml2 plugin (具体的代码实现就是 TypeDriver )。
但这只是一个表象,ml2还有更大的作用,那就是它里面的 MechanismDriver。

我举个例子讲,之前没有 ml2 的时候,plugin 只能支持一种,用了 linux bridge,就不能用 openvswitch 了,想要都用那怎么办,那就需要 MechanismDriver 上场,MechanismDriver 的作 用是将 agent 的类型 agent_type 和 vif_type 关联,这样 vif_type 就可以直接通过扩展 api 灵活设置了,所以这时候你想用 linux bridge 你在 vif_type 里直接将 port 绑定成 linux bridge 就行了,同理,想用 openvswitch 就将 vif_type 将 port 绑定成 openvswitch 就行。

除了让 openvswitch, linux bridg e这些不同的插件共存之外,ml2还能让不同的拓扑如 flat, vlan, gre, vxlan 其乐融融和谐共存,直接在 ml2_conf.ini 这个配置文件里都配上即可。这样也就解决了一个问题,以前前端horizon中无法配置是用 flat 还是 vlan,因为你配了也没有用,那时候后端还不支持 flat 和 vlan 同时存在了,现在皆大欢喜了。

上面的 ml2 解决的只是网络中 L2 层的问题,对于 L3 层的路由功能 neturon 又单独整出个 l3-agent,对于 dhcp 功能又单独整出个 dhcp-agent,不过它们归根结底仍属于实际真正干功能活的,对于和数据库 db 打交道的那部分则是通过提供扩展 api 来实现的。

那么现在我们想加更多的网络服务该怎么办呢,如 L4-L7 层的 FwaaS, VPNaaS, DNATaaS, DNSaaS,所以现在 neutron 又出来一个新的服务框架用于将所有这些除 L2 层以外的网络服务类似于上述 ml2 的思想在数据库这块一网打尽。并且这些网络服务可能是有序的,例如可能需要先过 FwaaS 防火墙服务再过 DNATaaS 服务来提供浮动 IP,所以也就有了 service chain 的概念。目前这块代码只进去了 firewall, loadbalance, metering, vpn 几块,但万变不离其宗,未来 neutron 就是朝这个思想继续往下做。想用哪些服务可以通过 neutron.conf 这个配置文件中的 service_provider 项指定。

最后,需要一提的是,从性能角度讲,我认为目前neutron仍然不能用于大规模的生产环境,理由如下:
1. 虽然增加了更多的插件,更多的网络服务,更多的网络拓扑,但它仍然不支持 multi-host 功能,对性能是极大影响
1. neutron-server 不支持 workers 通过 fork 实现的利用 cpu多核的多进程机制,仍然是单线程实现的,阻塞的话(python 解释器是单进程的,使用 greenlet 保证每个线程在单进程下也是线性的),会延缓接受其他请求对性能产生影响。
1. neutron-server 是无状态的服务,理论上讲是可以在多台机器上运行前端再加 haproxy 实现 HA 的,但实际代码中存在众多竞争条件的bug。当然这个问题不仅在 neturon有,其他组件我看一样存在。
1. 在遂道性能方面存在优化的可能,遂道如 GRE,VXLAN 等将虚拟 L2层打通反而扩大了广播风暴的可能,实际上虚拟网桥或者 hypervisor 都是知道虚机的 IP 和 MAC 地址的映射的关系的,根本不需要仍使用传统的 ARP 广播方式来获得这种映射关系。
1. 其他…

成熟的路上漫漫其修远兮,这也正好给各位爱好 openstack 的童鞋们提供了大显身手的好机会:)

本文固定链接: http://sdnhub.cn/index.php/openstack-neutron-evolution/ | 软件定义网络SDN

该日志由 sdnhub 于2015年05月20日发表在 OpenStack 分类下, 通告目前不可用,你可以至底部留下评论。
原创文章转载请注明: 用最精炼语言介绍OpenStack网络代码演进的前世今生 | 软件定义网络SDN
关键字:

用最精炼语言介绍OpenStack网络代码演进的前世今生:等您坐沙发呢!

发表评论

*

快捷键:Ctrl+Enter