SDN实战团分享(二十五):Midonet简介

编者的话】本文系SDN实战团微信群组织的线上技术分享整理而成,由北邮研究生张晨带来《Midonet简介》的分享。
-------------------------------------------------------------------------
嘉宾简介:
张晨:目前就读于北京邮电大学FNL实验室,网络与交换国家重点实验室。目前主要研究方向:软件定义网络,网络虚拟化,云数据中心网络。目前任职于Brocade。
------------------------------------------------------------------------
分享正文:

Midonet是日本的Midokura公司开源出来的Neutron组网方案。Midokura早在2010年就开始做云中的网络虚拟化,他们最开始做Midonet是用的python,后来为了便于在企业中落地改用了Java+Scala。2014年底的OpenStack大会上,Midokura将Midonet开源出来并集成到neutron plugin中,目前Midonet已经更新到了5.1版本。

由于起步较早,技术较为成熟,Midonet并已经在国外的一些企业中进行了落地。从members来看,既有eucalyptus、mirants这些云计算玩家,也不乏redhat、suse和ubuntu等开源IT界的老大哥,broadcom和fujitsu等通信巨头也赫然在列。从社区支持来看,Midokura号称开源版有6个月的Lifecycle Support,不知道是不是有忽悠的成分。

(一)架构

从组件来看,Midonet以Zookeeper+Cassandra构建分布式数据库存储VPC资源的状态——Network State DB Cluster,并将controller分布在转发设备(包括vswitch和L3 Gateway)本地——Midolman(L3 Gateway上还有quagga bgpd),设备的转发则保留了ovs kernel作为fast datapath。可以看到,Midonet和DragonFlow、OVN一样,在架构的设计上都是沿着OVS-Neutron-Agent的思路,将controller分布到设备本地,并在neutron plugin和设备agent间嵌入自己的资源数据库作为super controller。

从接口来看,NSDB与Neutron间是REST API,Midolman与NSDB间是RPC,这俩没什么好说的。Controller的南向方面,Midolman并没有用OpenFlow和OVSDB,它干掉了user space中的vswitchd和ovsdb-server,直接通过linux netlink机制操作kernel space中的ovs datapath。下图给出了host 中Midolman所处的位置。

根据目前Midokura官网给出的信息(http://www.midokura.com/midonet-community-edition/),开源版和企业版的Midonet能够支持的上游软件,网络功能,以及管理功能如下表所示:

开源版 企业版
上游软件
Hypervisor KVM KVM,ESXi
Container Docker Docker
Cloud Orchestrator OpenStack OpenStack,vSphere
Container Orchestrator Docker Swarm, Kubernetes* Mesos* Docker Swarm, Kubernetes* Mesos*
网络功能
L2 over L3
分布式路由
硬件VTEP
L3网关:EBGP + ECMP
安全:Port/Network
NAT:有状态/无状态/端口重定向
管理功能
REST API/CLI
GUI ×
Troubleshoot 支持的不好 支持的较好
日志 手动 自动

2015年10月份的时候,Midonet给出的roadmap如下所示 (http://www.slideshare.net/MidoNet/midonet-vision-roadmap):

  • Install:不间断升级、服务自动发现
  • Troubleshoot:P+V流量追踪,故障预测
  • Security:Service Injection,Neutron Tap-as-a-Service
  • Multi-Sites:VPNaaS,统一管理(5.1.0版本中实现)
  • Container:支持Magnum和Kuryr

(二)组网模型

Midonet是一款比较成熟的云网络虚拟化产品,它并不依赖于OpenStack存在,拥有自己的VPC资源描述和对应的Midonet API/CLI,这些资源的实时状态存在于NSDB Cluster中,通过RPC发布给Midolman。这些VPC资源可以看做是Overlay网络的组网模型,而Underlay网络的组网模型还是以VxLAN/GRE + IP Fabric为主体。

Midonet典型的Overlay组网模型如下图所示,对于Midonet Overlay资源的详细描述,以及它们与Neutron资源的对应关系,可参考https://blog.midonet.org/introduction-mns-overlay-network-models-part-2-tenant-routers-bridges/。


Midonet典型的Underlay组网模型如下图所示。

相比于Neutron的其它组网方案,Midonet中主要增加了对于public-network的支持。一般来说,Neutron的public-network中,各个tenant routers的external-interface与physical router interface在同一个CIDR下,这就会产生两个问题:1. 由于tenant router没有发布路由的能力,这就使得tenant间通信(在有FIP的情况下)只能走南北向流量的路由,得绕到physical router上再绕回来。2. Neutron社区目前缺乏public-network的控制机制。一来tenant router不支持做multi-home(尽管很早就有一个blueprint,https://wiki.openstack.org/wiki/Neutron/v2-public-networks,但一直也没见动静),二来缺乏动态的公网路由能力,没法做multi-site。

Midolnet解决这一问题的思路是,从Overlay角度增加了对Provider Router的资源描述,从Underlay角度增加了对L3 Gateway上的BGP的控制。Provider Router负责处理跨tenant的流量, Provider Router和L3 Gateway配合处理南北向流量。处理的机制后面再谈,下面只给出简单的示意。


另外,Midonet还增加了对baremetal server的支持,主要包括两种思路:
1. Physical network上的server与Host上的VM间通信,先走VxLAN到Hardware VTEP,在此终结VxLAN并根据二层的转发表从物理端口送出(Hardware VTEP上的物理端口要绑定VNI,需要的话还要绑定VLAN ID)。目前Midokura已经和Cumulus(一家linux networking厂商)进行了合作,( https://docs.cumulusnetworks.com/display/DOCS/Integrating+Hardware+VTEPs+with+Midokura+MidoNet+and+OpenStack)。
2. Physical network与Host直连,通过VLAN Aware Virtual Bridge标记VLAN TAG后从特定端口送出(https://blog.midonet.org/intro-to-mn-part-6-vlan-l2gateways/)。两种思路示意如下,具体工作机制这里就不讲了,大家有兴趣的话按照参考资料自行学习吧。

(三)Overlay Simulation转发逻辑

这一部分并没有叫做“流水线设计”,因为Midolman和OfAgent、Dragon Controller、OVN Local Controller这类OpenFlow控制器不同,它干掉了vswitchd和ovsdb-server,也就是放弃了OpenFlow和OVSDB,因此也没有了of pipeline的概念。Midolman直接通过netlink操作odp(ovs datapath),odp中的流表一般都是对流量进行exact match的,而且即使odp支持wildcard features,Midolman也不会采用,对此官方blog的解释是:“prefers more granular flows for statistics/counting purposes”。

下图的netlink channel下方就是Midolman的堆栈。当odp收到一个packet时,如果找不到流表就要上行向user space的Midolman发出upcall,Midolman首先查找odp flow-table的副本,没有查找wildcard flow-table,再没有就需要进入Overlay Simulation阶段了。之所以称为Simulation,是因为Midolman仿真了overlay中的各个设备(port traffic filter、vBridge、vRouter),packet会根据port binding的映射关系送入特定的overlay设备,这些设备存有overlay转发表(port traffic rule,L2 rule,L3 rule),因此也就具备相应的overlay转发能力,于是packet就会根据overlay转发表在Midolman中跑一次Overlay Simulation。Overlay Simulation过程中各个overlay设备的匹配字段和处理动作,会被整合成exact match + action set,然后翻译成一条odp流表项,下行送回odp。之后的相同类型的flow traffic就直接匹配该odp流表项完成处理了。

下面的图给出了Midolman的具体设计,大家对开发有兴趣的话可以参考参考。


当然,Midolman进行Overlay Simulation的前提是要了解Overlay和Underlay的拓扑以及资源映射关系。Overlay与Underlay的参数(包括host ip,port binding,MAC,IP,filter rule等)、以及网络的实时状态(L3 connection、LB、SNAT、L3 Gateway State)都存在于NSDB中,Midolman会通过RPC同步这些数据。

假设Midolman已经拿到了这些数据,现在vm1 通过tap123连接了ovs port 10,并第一次开始发包,最一般的过程抽象为dhcp + arp + ping。


Odp第一次看见dhcp/arp包,送给Midolman,Midolman也还不知道该怎么办,那就跑Simulation。首先,根据port binding的映射关系tap123对应着Overlay中的P5,于是就从P5进入其所在的vBridge开始Overlay上的转发 。

如果P5上配置了traffic filter,在送入vBridge之前还要先经过filter rule的处理,包括端口镜像、服务重定向、过滤三个过程。所以traffic filter的作用就是安全,对于dhcp/arp来说主要做Anti-Spoofing,对于ping和其它流量主要做Firewall。


进入vBridge后,就开始了vBridge的处理,vBridge中主要有ARP表和MAC转发表。对于arp则直接构造ARP Reply并从P5送出,下行送到odp后将action翻译为output=port 10,返回给vm1。对于dhcp、ping和其它流量,主要就是overlay上的L2转发。

Dhcp,router ping以及L3流量会经由vBridge送到vRouter,vRouter中主要就是路由表。对于dhcp/router ping,构造相应的dhcp/ping报文然后通过P3再次进入vBridge处理。L3流量的处理逻辑如下,还是典型的iptables的思路,不做过多解释。

南北向流量和Tenant间的流量会被Tenant vRouter中的静态路由送往Provider Router(上面的图里叫做Public Router),Provider Router对于一个cloud来说只有一个,由cloud operator进行管理。Provider Router的Internet路由表是L3 Gateway上运行的quagga bgpd形成的(默认情况下是static route),Midolman提供API和CLI对quagga bgpd进行控制,包括配置BGP Peer、发布BGP路由等等。Provider Router可以有多条Uplink(默认情况下是3条),相应地映射为不同L3 Gateway上的端口,可以支持ECMP和Failover。

以上就是Overlay Simulation主要的处理逻辑了。可以看到,虽然没有了OpenFlow Pipeline的概念,但是Midolman的设计还是体现了pipeline的思想,而且在实现上与传统的L2/L3设备中的pipeline是很像的。而且Overlay设备所具备的转发能力,使得Midolnet无论从业务平面、控制平面还是数据平面来说,都彻头彻尾地体现着网络虚拟化的思想。其实,ODL中的VTN实现网络虚拟化也是类似的思路,但是没有商业公司在后面推,实现的效果目前来看要比Midolnet差的远。

(四) 流表的情况

Midolman的处理再怎么精致,最后也需要体现到odp的流表中来。下面我们就来简单地看看odp中的流表情况。

先来看东西向流量。Compute host的odp上连接着tunnel port和VM port。由于Overlay Simulation所有的处理都是发生在src host上的,因此当发生跨host的时,为了使得dst host中的odp能够直接转发到vm,需要src host中的odp为流量标记tunnel id,而dst host中的odp要预置流表匹配tunnel id并直接转发给相应的vm。注意,tunnel id在Midolnet中并不表示segment,而是全局唯一地标识vPort(这里对应于vm,还有可能是L3 Gateway上的Uplink端口,见下文),存于NSDB Cluster中。

再来看南北向流量。Compute host上的odp通过dstIP识别出Internet流量,通过tunnel port送给L3 Gateway,并使用tunnel id标识L3 Gateway上的某一个Uplink端口。L3 Gateway中的odp连接着tunnel port,quagga port和uplink port,需要预置一些流表来处理BGP流量,如下图所示。至于南北向流量的流表,应该就是改MAC地址然后选一个uplink port送出吧。

这里的介绍没有涉及traffic filter,大家如果有兴趣可以参考https://blog.midonet.org/introduction-to-mn-part-4-security-groups/
--------------------------------------------------------------------------
SDN实战团微信群由Brocade中国区CTO张宇峰领衔组织创立,携手SDN Lab以及海内外SDN/NFV/云计算产学研生态系统相关领域实战技术牛,每周都会组织定向的技术及业界动态分享,欢迎感兴趣的同学加微信:eigenswing,进群参与,您有想听的话题可以给我们留言。


  • 本站原创文章仅代表作者观点,不代表SDNLAB立场。所有原创内容版权均属SDNLAB,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用,转载须注明来自 SDNLAB并附上本文链接。 本站中所有编译类文章仅用于学习和交流目的,编译工作遵照 CC 协议,如果有侵犯到您权益的地方,请及时联系我们。
  • 本文链接https://www.sdnlab.com/16974.html
分享到:
相关文章
条评论

登录后才可以评论

SDNLAB君 发表于16-06-01
1