OpenContrail架构浅析

SDN，即软件定义网络，从概念诞生之初就受到业界追捧。传统ISP基于专用物理设备的网络，业务灵活性差，系统资源利用率低，Capex和Opex居高不下。在新形势下，面对层出不穷的新业务需求，各大运行商纷纷推出自己的下一代网络规划，无不将SDN和NFV等纳入其中。同时，众多设备制造商及创业公司纷纷瞄准这个市场，推出自己的SDN解决方案，在此过程中，Juniper在2012年底收购Contrail之后将其SDN平台开源，称为OpenContrail。

虚拟网络（VN）是Contrail的核心概念，SDN的字面意思是软件定义网络，之所以能够对网络进行软件定义，核心也是在虚拟网络上，即根据需要，动态建立虚拟网络，这是理解SDN的关键。Contrail中，每个租户都可以拥有一个或多个虚拟网络，各个虚拟网络除非安全策略允许，一般都是互相隔离的。实现虚拟网络有多种方式，比如VLAN，VPN以及overlay networking。所谓overlay networking就是在物理网络之上建立的逻辑网络。这时，物理网络仅仅提供网络连通性，保证各物理结点，如路由器、交换机以及服务器等，网络可达，低时延、高可用，一般情况下，物理设备不包括任何租户信息，如租户的IP地址、policy等。而通过隧道技术搭建的上层网络，屏蔽了下层物理网络的不同类型、不同地域，甚至不同运营商，建立起各计算节点之间的连接，同时进一步能够通过虚拟路由表、策略等为不同租户隔离出私有网络，如下图。

应用场景

Contrail主要针对两种应用场景，一是私有云，二是NFV。

私有云，或者虚拟私有云（VPC）以及Iaas都涉及到多租户的问题。意味着所有租户共享物理资源（包括计算、存储、网络），但同时有自己独立的逻辑资源，这些逻辑资源互相隔离，互不干涉，租户并不清楚自己使用了哪些物理资源，但体验上就是服务提供商为自己搭建了一套私有网络，不但联通自己企业内部各站点，同时能够连接到其他物理网络上。

所谓NFV，即网络功能虚拟化，就是将现有各种物理服务器，如防火墙、IDS 、DPI等运行在通用x86服务器的虚拟机上，通过编排和网管系统，灵活地调度网络流量通过各种服务，这种方式提高了业务部署速度，降低了成本。关于NFV，请参考我的另外一篇文章。

系统组成

Contrial主要由两个层面组成，SDN控制器和虚拟路由器。正如SDN宣称的那样，控制平面和转发平面分离，Contrail作为一种典型的SDN实现，也遵循了这一设计准则。

Contrail SDN控制器负责管理、控制、分析运行在平台之上的各个虚拟网络，逻辑上集中，物理上分布部署，提供南北向和东西向接口。北向REST API可以被上层应用使用，与上层编排系统集成，例如Openstack，具体集成方式后面会详细讲，也用于与Contrail自己的GUI的交互。南向接口（包括XMPP、BGP、NetConf）用于与虚拟路由器和其他物理网元进行交互。东西向接口负责Contrail控制平面各节点的内部通信。

Contrail SDN控制器内部包含三大部分：配置节点、控制节点和分析节点，每种节点都能够运行多个实例，以达到HA和水平扩容的目的。各节点的作用以及内部实现会在后面详细讲。

虚拟路由器(vRouter)属于转发平面，运行在hypervisor上，包含两部分：位于用户空间的agent，负责与控制平面进行交互，以及一个作为Linux内核模块的转发引擎。在Contrail系统中，vRouter负责编织overlay network，各个vRoute之间通过动态隧道建立连接，它为每一个运行于其上的虚拟网络维护一个转发表，包括IP地址，Mac地址等信息。

Contrail的各种Node

Contrail的各种node都运行在activate-activate模式下，这样既能够支持冗余高可用又实现了水平扩容、负载分担。

配置节点：

Configuration node使用cassandra数据库保存了网络的期望状态，能够将代表期望状态的上层模型转化为适合进行网元配置下发的下层模型。

北向接口用于与其它编排系统或者应用对接，接收上层的配置。

Schema transformer在Redis消息总线上监听上层模型的变化，然后将其转化为下层模型的变化。比如上层模型的“create virutal network”会被转化为创建RT和RD，等等。

使用zookeeper作为分布式同步系统，分配全局唯一ID，保证全局事务。

控制节点：

Control node实现了一种逻辑上集中的控制平面，保存了网络的临时状态，通过各control node之间以及control node与虚拟/物理网元的交互来保证网络状态最终的一致性。Control node通过IF-MAP协议从configuration node接收配置，通过XMPP与vRouter agent交换路由，用BGP与网关设备交换路由，使用IBGP与其它control node保持路由同步。

分析节点：

Analytics node能够采集、存储、协调、分析来自各个网元的数据，包括日志、统计数据、events等。它提供北向Restful API供其它系统获取分析数据，使用Sandesh（基于XML的用于大量数据传输的协议）从其它node获取原始数据，规则引擎用于分析处理特定的event。查询引擎实现了一种类似与map-reduce的方式，将上层的单条查询转化多个查询，然后将结果汇聚起来。

除了上述三种node，Contrail系统还包括另外几种node类型。

计算节点：

Computer node，通用x86 Linux服务器，支持KVM和Xen作为hypervisor，虚拟机为租户提供各种网络服务，如防火墙、NAT等服务，能够组成service chain。

Computer node上运行vRouter，包括vRouter Agent和一个kernel module。

vRouter agent运行于用户态，主要作为控制平面和vRouter kernel module的桥梁，负责配置下发，状态上报，比如安装转发条目到流表（flow table）中，能够替代Linux bridge或者OVS，能够实现桥接（EVPN）或者路由（L3VPN）功能。另外，它也作为DHCP、ARP、DNS的代理存在。

vRouter kernel module实现报文在underlay网络和overlay网络收发时的封装和解封，发送报文到正确的路由实例中，应用流表中的转发策略。对于支持的报文格式，详见下面的通信协议一节。

网关节点：

Gateway node负责将虚拟网络接入物理网络，如Internet。

服务节点：

Service node用于运行各种网络服务，如DPI、IDP等。

通信协议

在数据平面，Contrail支持几种报文封装协议：

MPLS over GRE，实际上常见的L3VPN和EVPN使用的是MPLS over MPLS，但是Contrail是over GRE，主要原因是中间设备未必支持MPLS，或者没有使能MPLS。MPLS的payload是IP报文（对于3层overlay）或者Ethernet帧（对于2层overlay）。
VXLan，只能用于2层overlay
MPLS over UDP，同样可以用于2层或者3层的overlay。

在控制平面，control node之间以及与物理的网关之间使用BGP协议来交换路由信息，跟MPLS L3VPN或者EVPN用的相同。

配置节点和控制节点之间使用IF-MAP(Interface to Metadata Access Point)协议，这个协议比较陌生，没有找到太多资料，似乎官网都已经不可访问了。其设计初衷是采用订阅、发布的模式，将数据保存在一个可信任的网络中，通过提供统一的接口对外提供服务，核心能力是对数据的安全性保障。更多请参考百度文库上的文章。

在Contrail中，IF-MAP server运行在配置节点上，控制节点通过订阅发的方式，接收自己需要的信息。所有的高层和底层模型都在IF-MAP上有定义。

Contrail使用XMPP（The Extensible Messaging and Presence Protocol）来作为控制节点和计算节点的消息机制，传送包括路由、配置、统计信息、日志、事件等各种信息。

Sandesh，这个词具有浓烈的印度气息，暴露了Contrail的祖籍。Contrail使用这种基于XML的私有协议来收集运行数据，包括异步接收其他各种类型Node发送的日志、事件，主动查询各种状态数据。

openstack集成

上面提到了配置节点提供北向接口，可以和其他编排系统集成，这其中就包括Openstack，实际上Openstack应该是Contrail最重要的集成对象。

熟悉Openstack的同学应该清楚，在创建虚拟机时，Nova会向Neutron请求网络服务，并将虚拟机接入网络。Neutron实现了插件机制，支持很多种网络插件，能够提供不同的网络服务，例如DHCP、VPN等，实际上Contrail就是以Neutron plugin的形式集成到Openstack中。Contrail集成Openstack后，Nova创建的虚拟机会接入到Contrail的vRouter中，租户位于不同站点的虚拟机就通过vRouter搭建出属于自己的私有虚拟网络。上图除网络部分与Contrial相关外，其他都是正常的Openstack组件和交互。

Contrail的数据模型

Contrail无不骄傲的宣称它的架构其实是“SDN as a compiler”，仔细琢磨一下其实也好理解，就是将上层的网络模型”编译“成下层的网元模型，再说直白一点就是将网络需求转化为具体设备的配置。比如，将一个虚拟网络或者安全策略转化为BGP的RT、RD或者VXLAN的VNI等。

IF-MAP的模型实际上是一个有向无环图（DAG），有单根，包括结点（vertex）、线（connection）以及注解（annotation）。结点代表对象、实体，或者叫资源，连线表示结点之间的关系，比如父子关系、引用关系，每个结点可以有0到多个子结点，但是只能有1个父结点。

Contrail系统中任何状态，不管是配置、运行状态或者分析数据，都有对应的模型，都保存在Cassandra数据库中。

为了应对模型的变化，提高自动化程度，Contrial提供了根据模型自动生成代码的功能，根据xsd模型定义生成REST API以及内部的python class。

xsd文件片段：

<xsd:schemaxmlns:xsd="http://www.w3.org/2001/XMLSchema"xmlns:ifmap="http://www.trustedcomputinggroup.org/2010/IFMAP/2"><xsd:element name="foo" type="ifmap:IdentityType"/>
<xsd:element name="bar" type="ifmap:IdentityType"/><xsd:element name="foo-bar-link"/>
<!-- #IFMAP-SEMANTICS-IDLLink('foo-bar-link', 'foo', 'bar') -->
</xsd:schema>

最后，以3层单播报文为例说明同一租户的两个虚机之间是如何通信的。

1.VM1a虚拟机上的一个应用程序发送IP报文给VM2a

2.VM1a上有一条默认路由，指向169.254.*.*，在route instance 1a上的一个link-local地址。

3.VM1a发送一条查询这条link-local地址的ARP请求，route instance 1a响应请求。

4.VM1a发送IP报文给routing instance 1a。

5.routing instance 1a上的IP FIB 1a包含同一虚拟网络中所有虚拟机的32位路由（主机路由），包括VM2a，这些路由是控制节点通过XMPP协议下发给VRouter的。在发送到下一跳之前，需要：

添加MPLS报文头，MPLS标签由包含routing instance2a的vRouter2分配，这跟L3VPN中内层标签的分配方式一样。
添加GRE报文头，Compute Node2的IP地址作为目的地址。

6.vRouter1在全局FIB1中查询目的IP地址，即Compute Node2。

7.vRouter1将报文发送给Compute Node2，中间过程略过，因为是普通物理网络的报文转发。

8.Compute Node2在全局FIB2中查询收到报文的目的地址，发现是本地地址，所以解封装，去掉GRE头，暴露出MPLS头。

9.Compute Node2在全局MPLS FIB2中查询MPLS标签，发现是routing instance 2a的，于是去掉MPLS报文头，将报文注入的routing instance 2a。

10.Compute Node2在IP FIB 2a中查询内层IP地址，发现指向连接VM2a的接口，于是将报文发送给VM2a。