英文原文：http://opencontrail.org/opencontrail-architecture-documentation/

翻译者：@KkBLuE知行合一  其微信号：kkbluepublic， SDNAP.com翻译整理

OpenContrail 体系架构文档

1  概述
1.1  使用案例
1.2  OpenContrail控制器和vRouter
1.3  虚拟网络
1.4     Overlay Networking
1.5     Overlays based on MPLS L3VPNs and EVPNs
1.6     OpenContrail and Open Source
1.7  扩展架构和高可用性

1.8  数据模型中心规则：SDN作为编译器存在
1.9  北向应用程序接口
1.10  GUI用户端口
1.11  扩展平台

2  体系细节
2.2  OpenContrail转发平面
2.3  服务链
2.4  控制和管理平台协议
2.5  集成
2.6  安全
2.7  层次化扩展和高可用性
3  数据模型
3.1  编程模型
3.2  配置和运维数据模型

4  OpenContrail用户案例
4.1  数据中心域用户案例
4.2  运营商网络NFV

5  比较OpenContrail系统和MPLM VPN

6  缩略语表

7  参考文档

1  Overview of OpenContrail

本章节介绍OpenContrail系统—一个SDN的扩展平台

所有主要内容在本章中都有简略介绍，详细内容会在后续章节中继续描述

OpenContrail是一个扩展系统，可以应用在不同的网络环境中，但是，其使用的主要驱动力在于如下两个体系结构下

• 云计算网络-企业和运营商的私有云网络提供体系即架构-IAAS服务和云服务提供商提供的虚拟私有云（VPCs）服务
• 在运营商网络中的网络功能虚拟化（NFV）--为运营商边界网络提供增值服务，如提供业务边界网络，宽带用户管理边界网络和移动边界网络

私有云，虚拟私有云（VPC）和基础架构即服务（IAAS）的使用场景里，都需要多租户虚拟数据中心，在这些案例中，都在一个数据中心中存在多个租户，共享相同的物理资源（物理服务器，物理存储和物理网络），每个租户被指定使用他们自己的逻辑资源（虚拟机，虚拟存储，虚拟网络），这些租户的逻辑资源之间相互隔离，除非基于某些安全策略使之可以相互访问，数据中心中的虚拟网络一样可以通过物理的IP VPN或者L2 VPN进行互联网络功能虚拟化（NFV）的使用场景中引入了协调器和网络管理功能，例如防火墙，入侵检测系统，深度包检测，数据缓存，广域网加速等等，这些功能在虚拟机中实现，从而替代了以往的传统物理设备，这些，都驱动了网络层面的虚拟化，使其可以走向市场，优化网络成本

OpenContrail系统由两个主要部件组成：OpenContrail控制器和OpenContrail虚拟路由器

OpenContrail控制器是一个逻辑上集中但是物理上分布的SDN控制器，为虚拟网络提供管理，控制和分析功能。

OpenContrail vRouter（虚拟路由器）是一个转发平面（或者是分布部署的路由器），运行在虚拟服务器的hypervisor，将网络从一个数据中心的网络的物理路由器和交换机扩展成一个虚拟的基于虚拟服务器主机之间通讯的overlay网络（关于overlay网络的详细介绍将会在1.4章节中,OpenContrail虚拟路由器从概念上和现在的商用和开源vSwitch（如OVS）很像，但是他会提供路由以及更高层的服务（使用vRouter替代vSwitch）

OpenContrail控制器提供了系统的逻辑集中控制平面和管理平面，并且协调管理vRouter

虚拟网络是OpenContrail系统的重要部件，虚拟网络是部署物理网络顶层的逻辑架构，虚拟网络也用于替代基于VLAN隔绝网络的方案，为多租户提供虚拟数据中心，每一个租户或者应用可以拥有一个或者多个虚拟网络，每个虚拟网络之间相互隔绝，除非使用安全策略允许之间相互访问

虚拟网络通过在数据中心的边界路由器上使用MPLS L3 VPN或者EVPN，作为物理网络连接扩展使用（译者注，实际上是使用这些技术实现跨数据中心的虚拟化）

虚拟网络同样可以使用部署在NFV环境和服务链上，详细内容会在2.3中介绍

虚拟网络也可以使用在两个网络中—物理underlay网络或者虚拟overlay网络。Overlay网络技术已经广泛应用在无线局域网产业十年以上，但是现在数据中心网络为之赋予了新意，并且被不同的组织标准化，例如IETF下属的NVO3工作组，并且通过不同厂商的开源或者商业网络虚拟化产品进行部署

物理底层网络的作用，就是提供的一个“IP矩阵”，他的职责是提供所有物理设备之间的单播IP可达性（服务器，存储设备，路由器或者交换机），一个理想化的底层网络，可以提供网络中任意一点之间的低延迟，无阻塞和高带宽连接

虚拟路由器运行在虚拟服务器的hypervisor层，通过在物理底层网络的上层创建虚拟overlay网络，使用动态的“通道”网，保证虚拟服务器之间的连通性，在OpenContrail overlay通道中，可以使用MPLS over GRE/UDP通道，或者VXLAN通道。

底层物理路由器和交换机不需要保存任何租户的信息：他们不需要保存任何MAC地址，IP地址或者虚拟机之间的策略，在底层物理交换机和路由器的转发表中，只会包含物理server的IP前缀或者MAC地址。网关路由器或者交换机是一个特例，因为他们需要保证虚拟网络和物理网络的通讯，他们需要包含租户的MAC或者IP地址信息

从另一个方面说，虚拟路由器会包含每一个租户的信息，他们会包含每一个虚拟网络的独立转发表（或者称为一个路由实例），这些转发表包含虚拟机的IP前缀（在L3 overlay网络中）或者MAC地址（在L2 overlay网络中），并不是一个虚拟路由器需要保存整个数据中心所有虚拟机的所有IP前缀或者所有MAC地址信息，给定的虚拟路由器只需要保存本地服务器存在的路由实例的信息上（举例说明，至少每个服务器上存在一个虚拟机）译者注：实际上就是每个虚拟路由器会负责一个每一个物理server上的虚拟机内部，或者之间的通讯，会保存路由表，转发表等

厂商和标准化组织已经提出了真对于overlay网络的各自不同的控制平面和数据平面协议

例如，IETF VXLAN提出了一个新的数据平面封装，并且提出了一个和标准以太网“泛洪和学习源地址”，进而形成L2转发表的行为类似的控制平面协议，需要在底层网络部署一个或者多个组播组来实现泛洪

OpenContrail也受此类技术的影响，其解决方案在概念上类似于标准的MPLS L3VPNs (用于 L3 overlays)和 MPLS EVPNs (用于 L2 overlays)

在数据平面，OPENCONTRAIL支持MPLS over GRE，这种数据平面的封装可以被目前的大部分主流厂商的现有路由器支持，OPENCONTRAIL同时支持其他数据平面封装标准，例如MPLS over UDP (在多路径和CPU优化上更具优势) 和 VXLAN，其他的封装标准例如NVGRE会非常容易添加在后续版本中

OPENCONTRAIL系统的控制平面或者物理网关路由器（或者交换机）之间的控制平面协议是BGP（以及使用Netconf用于管理），这也同MPLS L3VPN 和 MPLS EVPN使用的控制平面协议相同。

用于OPENCONTRAIL控制器和OPENCONTRAIL虚拟路由器之间的协议基于XMPP，XMPP信息的交互方式在IETF草案上已有描述，尽管语法不同，但是语意上和BGP非常相似

实际上，OPENCONTRAIL系统使用的控制和转发平面协议与MPLS L3VPN和 EVPN协议非常类似，这样做存在诸多好处：这些协议比较成熟，而且易于扩展，被广泛应用在生产网络，并被多个厂商产品支持，可以无缝互操作，而无需软件网关（译者注：最后一句话实际上是重点，使用老技术来保证新部署模式不需要更新硬件设备）

OPENCONTRAIL被设计可以运行在一个开源云网络环境中，用于提供完整的集成端到端的解决方案

• OPENCONTRAIL系统可以和开源的hypervisor集成，例如KVM和XEN
• OPENCONTRAIL系统可以和开源的虚拟化协调协同集成，例如OpenStack和CloudStack
• OPENCONTRAIL系统可以和开源的服务器管理系统集成，例如chef, puppet, cobbler和 ganglia.

OPENCONTRAIL目前遵从Apache 2.0许可，这意味着任何人可以开发和修改OPENCONTRAIL系统代码，不需要承担公布或者释放修改代码的任何义务

Juniper网络同时提供OPENCONTRAIL系统的商用版本，为Juniper网络和其代理商提供整个开源栈（不仅是OPENCONTRAIL系统，还包括其他开源组件如OpenStack）的商业支持

OPENCONTRAIL系统的开源版本不是一个“戏弄者”（译者注：不是随便玩玩的版本），会提供和商用版本一样的功能，以及扩展性

前文我们提到，OPENCONTRAIL控制器是一个逻辑集中化的平台

物理分布意味着OPENCONTRAIL控制器结合不同类型的节点，每一个都可以有多个实例，提供高可用性和层次化扩展，这些节点实例可以是物理服务器或者虚拟机，最小部署环境下，这些节点可以合并在一个server上，整个系统一共三个类型的节点

• 配置节点主要负责管理层，控制节点提供北向REST应用程序接口（API），可以用于配置系统，或者获取系统的运行状态信息，使用层次化数据库组件表现实例服务，实例化的服务是以一个可横向扩展的数据库为对象，而这个数据库通过一个正式的服务数据模型所描述（更多的数据模型在后面描述）。配置节点同时也包含一个转换引擎（有时可以理解为编译器），将高层级服务数据模型的组件转换成相应的更多的低层级技术数据层面的组件。也就是说，高层级服务数据模型描述什么服务需要被部署，而低层级技术数据模型描述什么服务通过什么技术怎样被部署，配置节点使用IF-MAP发布低层级技术数据平面的内容给控制平面。
• 控制节点部署在控制平面的逻辑集中部分，不是所有的控制平面功能全部逻辑集中—一些控制平面的的功能依然会在网络中的物理和虚拟路由器上以当前流星的分布式的方式部署（译者注：也就是说控制平面的功能也会向以前的组网一样，在每一个路由器或者交换机上），控制节点使用IF-MAP协议监控底层技术数据模型的内容，并通过配置节点进行计算描述网络的需要状态。控制节点使用南向协议的集成来达到“使其成真”的目的，例如把网络的实际状态等同于网络实际需要的状态（译者注：就是按需定义网络），当前的初代版本，OpenContrail系统的南向协议包括XMPP去控制OpenContrail虚拟路由器，XMPP集成了BGP和Netconf协议去控制物理路由器，控制节点同时使用BGP去进行其他节点控制节点多个实例的状态同步，来达到扩展和高可用性的目的。
• 分析节点的职责是收集，核对和展示分析信息，用于排除网络故障和了解网络的使用情况，每个OpenContrail系统的组件会产生系统中每一个显著事件的详细记录，这些时间记录会发送给分析节点一个或者多个实例（扩展目的），在一个层次化可扩展的数据库中核对和储存信息，提供更便于时间系列分析和查询的优化数据格式。分析节点具有事件发生时自动触发和收集详细信息的机制，目标是可以获取任何问题的故障原因，而无需重现故障。分析节点提供被北向分析查询REST API。

OpenContrail控制器的物理分布式特性是一个特殊的功能，因为这可以使任何节点的多个冗余实例，运行在主-主模式（另一种模式是主备模式），系统可以在任意节点故障时持续工作而不会有任何中断，当节点变得超载，节点的其他实例将会被实例化，负载可以自动重新分布，这样可以防止单一节点成为瓶颈，使得系统可以具备极大的扩展性---支持数以万计的服务器

逻辑集中意味着OpenContrail系统的行为是一个单一的逻辑点，尽管实际上他会部署成为集群或者多个节点

数据模型扮演着OpenContrail系统中的中心角色，一个数据模型包括设置的组件，性能，和数据模型之间的关系。

数据模型允许应用可以快速宣告而不是经由某种必要行为来实现，这是实现程序高效的关键所在，OpenContrail架构的基本目标就是平台上的数据操作，就如同平台上维护的应用一下，也就意味着应用的处理是无状态虚拟化的，更重要的结果是这个设计可以让独立的有那个用可以从复杂的网络操作解放出来，不需要担心其高可用性，扩展性和互联性。（译者注：个人理解是OpenContrail希望达到的目的是业务的快速部署，以前部署业务，除了服务器上面配置之外，还需要在网络层进行进一步的配置，而OpenContrail里面的数据模型可以让应用快速通告，而不担心基础架构网络的调整）

有两类数据模型：高层级数据模型和低层级数据模型，这两个数据模型都使用格式化数据模型语言—目前使用的是IF-MAP的XML语法，YANG也会在未来的版本中被考虑作为模型化语言

高层级服务数据模型在抽象化的最高层描述网络所需要的状态，使用组件直接将服务对应到终端用户上，例如，虚拟网络，连接策略或者安全策略等

低层级技术数据模型描述在抽象层中非常底层的网络所需要的状态，使用组件来对应特定的网络协议，例如BGP的路由标记（RT）或者VXLAN的网络标识

配置节点的职责就是将高层级服务数据模型的修改转换成低层级技术数据模型的修改，这在概念上和即时编译（JIT）类似，借此“SDN即为编译器”在有时用于描述OpenContrail系统的体系结构

控制节点的职责是识别网络需要的状态，这种状态被使用北向协议如XMPP，BGP和Netconf这些北向协议的集合形成的低层级技术数据模型所描述。

译者注：这段比较晦涩难懂，但是整体看来并不复杂，重点在于，我们要从数据中心应用的角度去理解，简单来说，数据中心内部服务器上需要跑各种类型的服务，这些服务之间的通讯靠数据中心内部的交换机以及路由器实现，在以前的部署环境中，当我们开启一个业务，或者说在数据中心中建立一个业务分区，那么我们需要做的是，在物理机或者VM上安装服务，然后，根据服务的要求，建立和其他分区的流量转发策略以及安全策略，这需要在不同的设备上去进行配置来实现一个业务的开局，那么在“SDN”的环境中，我们现在把数据中心想象成一个整体来考虑，其中，交换机等基础架构的工作是只需要提供一个物理接口，接下来要做的就是有一个集成化的工具，也就是OpenContrail系统，从创建虚拟机开始，一路next，直接把服务开启，网络也瞬间进行调整，这样实现“SDN”的目的，在这个思路下，上面的高层级和低层级，控制和配置模型的介绍，实际上就是事先这个思想的技术而已。

OpenContrail控制器中配置节点为预留或协调系统提供北向REST API接口，北向REST PAI会由格式化的高级数据模型创建。这保证北向REST API是“第一批市民”，意味着任何服务可以通过REST API进行预留

REST API采用安全通讯方式：使用HTTPS用于验证和加密，并且提供基于策略的授权，同时具有层次化的扩展，因为API可以被多个配置节点实例读取

OpenContrail系统也提供图形化接口，GUI在使用REST API 描述前构建完成，保证不会在API内产生延迟，同时，我们预期大规模部署或者运营商OSS/BSS系统可以使用REST API集成于此

附注：我们正在进行UI 代码级别的修改，以便未来允许我们可以使其开源

OpenContrail系统的初代版本使用特定的高层级服务数据模型，特定的低层级技术数据模型，以及转换引擎进行前者后者的映射，此外，OpenContrail系统的初代版本也是用特定的南向协议集合

高级服务数据模型在OpenContrail系统的初代版本中的模型化服务结构包括：租户，虚拟网络，连接策略和安全策略，选择这些模型组件支持的基本业务环境主要是云计算网络和NFV（适用环境：云计算网络，多租户网络）

低层级服务数据模型在OpenContrail系统的初代版本中主要面向的服务部署模型是使用overlay networking（网络构建模型：overlay）

配置节点的转换引擎包括“编译器”去实现高层级服务数据模型到低层级数据模型的转换映射

初始版本控制节点使用的南向协议包括XMPP，BGP，Netconf

OpenContrail系统是一个扩展平台，意味着，在未来的版本中，我们可以通过组件扩展的方式去支持更多的用户部署环境和网络技术

• 高级服务数据模型可以扩展新的组件去支持新的服务，例如：运营商核心网络的流量工程和流量日历（根据日期进行流量管理）
• 低层级服务数据模型也可以基于其中一个原因进行扩展，相同的高级服务使用不同的技术去进行部署，例如，多租户可以使用VLAN去替代overlay，新的高层级服务的引入会需要新的低层级技术，例如引入流量工程或者流量日历作为高级服务就需要引入新的低层级组件例如TE-LSP

译者注：这章定义了OpenContrail系统的使用环境：用于云计算或者多租户的数据中心，采用overlay的网络模型，当然，作为一个可以扩展的系统，在未来版本中，可以根据业务的需要增加新的服务，但是有了新的服务，也就需要新的技术。

• 转换引擎可以为映射现在的高级服务组件到新的低层级技术组件（实现当前业务的新的方式或者新的网络技术），或者映射新的服务组建到新的或者现有的低层级技术组件（例如部署新服务）进行扩展。

新的南向协议可以引入到控制节点中，这主要用于支持网络中使用不同协议的新类型的物理或者虚拟设备。例如特定厂商的网络设备使用的CLI命令行接口可以被引入，或者可能因为需要部署新的协议，新的组件需要引入到低层级技术数据层面中。

2  OpenContrail系统结构细节

如图1所示，OpenContrail系统包含两个部分：一个逻辑集中但是物理分布的控制器和一个vRouter(虚拟路由器)的集合，使用软件转发模式部署在通用虚拟服务器的hypervisor层

控制器提供北向REST API接口供应用使用，这些API用于和云协调系统集成，如通过neutron（以前叫做quantum）和Openstack集成，REST API也可以被其他应用以及或运营商的OSS/BSS系统使用，最终，REST API被部署在OpenContrail系统内基于网页的GUI集成

OpenContrail系统提供三个接口：北向接口集合用于与协调系统和应用通讯，南向接口用于与虚拟网络环境（虚拟路由器）或者物理网络环境(网关路由器和交换机)通讯，东西向接口用于和其他控制器对等通讯，Openstack和CloudStack支持协调器，标准BGP用于东西向接口，XMPP用于虚拟路由器的北向接口，BGP和Netconf和南向接口用于网关路由器和交换机。

在内部，控制器包括三个主要组件

• 配置节点的职责是通过网络环境的协作，为高层级数据模型到低层级数据模型提供转换。（译者注：把上层的应用使用底层技术进行实现）
• 控制节点的职责是在网络环境和对等系统之间进行低层级状态信息的转播，保证整个环境的信息一致。（译者注：进行信息同步，例如BGP信息，路由信息等）
• 分析节点的职责是记录网络环境的实时状态，抽象化数据，并且适宜表现出来供应用进行使用（分析数据，呈现数据）

所有的节点都会在本章的后面详细描述

虚拟路由器将通过软件方式部署在网络环境中，他们的责任通过服务器到服务器之间的通道进行一个虚拟机到另一个虚拟机之间的数据包转发。这些overlay网络的通道位于物理IP-over-Ethernet网络的上层。每个虚拟路由器包含两个部分：一个用户空间代理部署控制平面，一个内核模块部署转发平面。

OpenContrail系统部署三个基本区块

1.多租户，也被理解为网络虚拟化或者网络分片，用于创建虚拟网络，提供CUG（封闭用户组）设置虚拟机

2.网关功能：通过网关路由器连接虚拟网络到物理网络（或者互联网），连接非虚拟化的服务器，或者通过网关连接虚拟网络的网络服务。

3.服务链：也被理解为NFV，通过物理或者虚拟网络服务（例如防火墙，深入包检测，负载均衡）形成一个有序的流量服务流

2.1.1 节点

我们转到系统的内部服务架构上，如图2所示，系统通过通用x86服务器运行的相互协作的节点集合进行部署，每个节点可以部署在独立的服务器上或者部署在一个虚拟机上

所有给定类型的节点使用A-A配置运行来保证单点不会形成瓶颈，这种扩展化的设计提供冗余和层次化的灵活性。

• 配置节点保留一个预计配置状态的持续备份，并且为适应网络环境的互操作从高层级数据模型到低层级数据模型的转换，这些都保存在一个NoSQL的数据库中
• 控制节点部署一个逻辑集中的控制平面，旨在维护一个短暂的网络状态，控制节点之间以及和网络基础架构设备之间互操作，在保证网络状态的持续一致。
• 分析节点搜集，存储，关联和分析虚拟和物理网络环境中的信息，这些信息包括统计，日志，事件和错误。

另外一些节点类型也作为OpenContrail控制器的一部分，我们同时也在物理服务器和物理网络环境中定义了一些另外的节点类型，来在整个OpenContrail系统中执行一些特定的规则

• 计算节点是运行虚拟机的通用物理服务器，这些虚拟机可能是租户运行通用应用，或者这些虚拟机可以运行虚拟网络服务，例如虚拟负载均衡或者虚拟防火墙，每一个计算节点都包含一个虚拟路由器，部署转发平面和分布式控制平面（计算节点实际上就是物理服务器）
• 网关节点是一个物理网关路由器或者交换机，连接租户虚拟网络到物理网络（互联网，客户VPN，另一个数据中心或者非虚拟化的服务器）中来
• 服务节点物理网络环境提供诸如深度包检测（DPI），入侵检测（IDP），入侵防护（IPS），广域网优化和负载均衡，服务链可以包含这些虚拟服务的汇集（例如在计算节点中的虚拟机）和物理服务器（在服务节点中）

为便于理解，图中没有展示在下层IP over Ethernet 网络中的物理路由器和交换机。同事，在每个节点中和分析节点中存在一个接口，为避免混乱，这个接口在图2中也没有展示。

2.1.2 计算节点

计算节点是一个通用的x86架构服务器，作为VMs的承载。这些虚拟机可以是租户的虚拟机，运行客户的应用，例如网页服务器，数据库服务器，或者企业应用，或者这些虚拟机可以运行虚拟服务，用于创建服务链，标准的配置是使用KVM或者Xen作为hypervisor，上层运行Linux，虚拟路由器的转发平面在Linux 的Kernel中，虚拟路由器的代理作为逻辑控制平面，其整体接口如图3所示

其他支持的OS或者hypervisor例如VMware ESXi或者Windows Hyper-V可能会在未来支持。

计算节点部署的虚拟路由器包括两个区块：虚拟路由器代理和虚拟路由器转发平面，这些将会在后续描述。

2.1.2.1虚拟路由器代理（虚拟路由器）

虚拟路由器是一个用户空间进程，在Linux中运行，是一个本地的，轻量控制平面，主要提供如下功能

• 使用XMPP实现和控制节点的例如路由的控制状态交换
• 使用XMPP从控制节点上接收低层级配置状态，例如路由进程和转发策略
• 向分析节点汇报例如日志，汇总和事件的分析状态
• 向转发平面安装转发状态（下发转发表）
• 查找VM的存在和属性，和Nova代理进行交互
• 为每个新流的首包应用转发策略，在转发平面的流表安装流表项
• 为DHCP，ARP和MDNS提供代理，其他代理会在未来版本中添加

每个虚拟路由器都会连接至少两个控制节点，在A-A冗余模型中提供冗余

2.1.2.2 虚拟路由器转发平面

虚拟路由器转发平面运行在Linux的kernel中，主要负责如下功能

• 封装数据包到overlay网络中，从overlay网络中解封装数据包
• 分配数据包到路由实例中
  • 从overlay网络中接受数据包，并基于MPLS标签或者虚拟网络标识（VNI）分配到路由实例中
  • 为虚拟机提供虚拟接口，并绑定在路由实例中。
  • 在转发信息表中进行对于目的地址的查表，并转发数据包到正确目的，路由可以基于三层IP前缀或者二层MAC地址。
  • 可选项—在转发表中应用转发策略。
    • 匹配流表中的数据包，并应用流表操作
    • 可选项—当安装转发规则在流表虚拟路由器转发数据时，没有找到流规则时挂起数据包（译者注：这段不好翻译，用防火墙的方式就好理解了，防火墙利用流表转发数据，但是流表是根据rule规则来执行，通过首包创建流表，进而，当收到首包时，还没有出现流表，就会根据规则创建流表，这时这个数据包是会被暂时缓存）
    • 在虚拟路由器中挂起诸如DHCP，ARP，MDNS等数据包用于代理

图四介绍了虚拟路由器转发平面的内部结构

转发平面在overlay网络中支持MPLS over GRE/UDP和VXLAN封装，转发平面支持三层转发，对目的地址进行最长掩码匹配（LPM），也支持进行二层转发，基于MAC地址。当前虚拟路由器的转发平面支持IPv4，未来会支持IPv6

2.2会介绍更多细节

2.1.3 控制节点

图5介绍控制节点的内部结构

控制节点和多个类型的节点进行通讯

• 控制节点使用IF-MAP从配置节点接受配置状态
• 控制节点使用IBGP和其他控制节点交换路由，保证所有的控制节点保存相同的网络状态。
• 控制节点使用XMPP和在计算节点上的虚拟路由器交换路由，他们同样也使用XMPP发送配置状态，例如路由实例和转发策略
• 控制节点同时代理计算节点方面的某些流量，这些代理请求同样使用XMPP接收
• 控制节点使用BGP和网关节点（路由器和交换机）交换路由，他们使用Netconf发送配置状态

2.1.4 配置节点

图6展示配置节点的内部结构。配置节点通过REST接口和协调系统通讯，和其他配置节点通过分布式同步机制通讯，使用IP-MAP和配置节点通讯。

配置节点同时提供查询服务，客户可以用于定位本地提供服务（例如其他节点提供特定服务），例如，当计算节点的虚拟路由器想要连接一个控制节点（更准确说，一对A-A控制虚拟机的另外一个），用于服务查询控制额节点的IP地址，客户使用本地配置，DHCP或者DNS定位服务查询服务器。

配置节点包含如下组件

一个REST API服务器提供北向接口到协调系统或者其他应用，这个接口用于使用高层级数据模型安装配置状态

一个Redis信息总线，用于内部组件中的通讯。

一个Cassandra数据库用于持续存储配置，Cassandra是一个可容错并且层次化扩展的数据库。

一个Schema转换器，学习通过Redis信息学习高层级数据平面的修改，并且转换（编译）这些高层级数据模型的改变到低层级数据层面

• 一个IF-MAP服务器提供南向接口，推送计算过的低层级配置到控制节点

Zookeeper（图中没有现实），用于分配独立的组件标识，并且部署

2.1.5 分析节点

图7介绍分析节点的内部结构，分析节点使用北向REST API和应用进行通讯。使用分布式同步机制和其他分析节点同步，使用基于XML的协议与控制节点和配置节点的组件通讯（基于XML的协议叫做Sandesh，设计用来处理数据的高值）

分析节点包含如下组件

• 一个收集器，与控制节点和配置节点交换Sandesh信息，收集分析信息
• 一个NoSQL数据库存储这些信息
• 一个规则引擎，当特定事件发生时自动收集运行状态
• 一个REST API服务器，提供北向接口，用于查询分析数据库和检索操作状态
• 一个查询引擎，通过北向RESTAPI执行查询接收，这个引擎为潜在的大型分析数据中提供灵活访问的能力

Sandesh 携带两类信息：异步信息从分析节点中接受，目的是汇报日志，事件和监控，同步信息用于分析节点向特定的操作状态发送请求和接受响应，

所有的信息通过收集器收集并持续的保存在NoSQL数据库中，信息源不会做任何过滤。

分析节点提供北向REST API接口允许客户应用提交查询。

分析节点提供分散收集逻辑，叫做“聚合”，一个单一的GET请求（一个客户应用对应的CLI命令）可以映射到多个请求信息，并且形成组合的结果。

查询引擎是一个简单的Map-reduce引擎，OpenContrail最主要的查询是时间系列。

转发平面部署在一个overlay的网络中。Overlay可以是三层IP的overlay网络或者二层（以太）overlay网络。对于三层overlay，目前只支持IPv4，IPv6会在后续版本中增加，三层overlay网络支持单播和组播，代理可以避免DHCP，ARP以及其他协议的泛洪

2.2.1 包封装

系统支持多种overlay封装格式，每个封装会在后续介绍

2.2.1.1  MPLS over GRE

图8介绍了针对L3的overlay的MPLS over GRE包格式

图9介绍了针对L2的overlay的MPLS over GRE包格式

MPLS L3VPN和EVPN都是使用MPLS over MPLS的封装格式，但是也可以在核心网络没有使用MPLS的情况下使用MPLS over GRE。OpenContrail系统使用MPLS over GRE而不使用MPLS over MPLS有诸多原因：第一，数据中心的底层交换机经常不支持MPLS，第二，即便支持，运维人员也不希望数据中心因使用MPLS儿变得复杂化，第三，因为在数据中心中带宽都足够预期，不需要使用流量工程

2.2.1.2  VXLAN

对于L2的overlay，OpenContrail系统同样支持VXLAN封装，如图10所示

使用VXLAN封装的诸多好处之一是可以通过在外层头部的UDP源端口注入entropy（词库翻译成墒-内层包头的哈希）的特点支持底层的多路径

OpenContrail部署VXLAN和VLAN IETF草案标准有两个显著的不同，第一，仅仅遵从IETF 草案的的数据包封装格式，没有使用其泛洪和学习的控制平面内容，取而代之的是使用基于XMPP协议的控制平面实现（在本章中有描述），第二，出口虚拟路由器的VXLAN包头的虚拟网络标识为本地唯一，替代了全局唯一。

2.2.1.3       MPLS over UDP

OpenContrail支持第三种封装—MPLS over UDP，这综合MPLS over GRE和VXLAN封装，支持二层或者三层的overlan，是用一个“内层”MPLS包头作为本地MPLS标签标识，用于识别目的路由实例（类似于MPLS over GRE），但是是用一个外层UDP包头，便于底层网络的多路径传输（类似VXLAN）

图11 显示了MPLS over UDP封装支持三层overlay

图12 显示了MPLS over UDP封装支持二层overlay

2.2.2  Layer 3 Unicast   三层单播

下面介绍VM 1a到VM 2a发送一个IP 数据包的逐一流程，详细内容可以参考 [draft-ietf-l3vpn-end-system].，这个流程描述的是IPv4，而IPv6在步骤上类似。

1.VM 1a上的应用发送一个数据包，目的地址是VM 2a

2.VM 1a有一个缺省路由指向路由实例 1a的169.254.x.x 本地地址

3.VM 1a为这个本地地址发送一个ARP请求，在路由实例 1a上的ARP 代理进行响应

4.VM 1a发送IP数据包到路由实例 1a

5.在路由实例1a上的IP FIB（IP转发信息表）会包含相同虚拟网络中其他所有VM的32位路由，包括VM 2a。这些路由是控制节点通过XMPP安装。对于下一条路由会具有以下操作

a.压入一个MPLS 标签，该标签为虚拟路由器2 为路由实例2a分配。

b.压入一个GRE标签，目的地址为计算节点2

6.虚拟路由器1 通过全局 IP FIB1 查找封装包新的目的IP（计算节点2的IP）

7.虚拟路由器1发送封装后的数据包到计算节点2，下一步如何发生，将根据底层网络是使用二层交换网络还是三层IP网络，这部分描述会在后面介绍，现在我们先忽略这个步骤，设定封装过的数据包已经传送到了计算节点2

8.计算节点 2 接收封装后的数据包，并开始在全局 IP FIB 2上进行IP查找，当外层目的IP就是本地地址时，会进行解封装，移除GRE头，显示出MPLS头

9.计算节点 2 在全局 MPLS FIB 2中执行MPLS标签的查找，查找到表项定位在路由实例 2a上，解封装包头，移除MPLS标签，并把解封装后的数据包发送进入路由实例 2s

10.计算节点2a 在IP FIB 2a中进行解封装后的内层IP地址的查找，定位路由指向连接VM2a的虚拟端口

11.计算节点 2 发送数据包到VM 2a

现在我们回到刚才步骤7略过的部分，如果把封装后的数据包通过底层网络转发。

如果底层网络是二层网络，那么：

1.封装数据包的外层源IP地址（计算节点1）和目的IP地址（计算节点2）在同一个子网

2.计算节点1 发送对于计算节点2的ARP请求，计算节点2发出ARP响应，包含计算节点2的MAC地址，注意，在底层网络中没有ARP代理封装的数据包

3. 通过二层交换基于目的MAC地址从计算节点1发送到计算节点2

如果底层网络是3层网络，那么：

1.封装数据包的外层源IP地址（计算节点1）和目的IP地址（计算节点2）在不同子网

2.所有包括物理路由器（S1和S2）和虚拟路由器（虚拟路由1和虚拟路由器2）底层网络的路由都在运行某一个路由协议（如OSPF）中

3.封装后的数据包通过三层路由基于目的IP地址从计算节点1到计算节点2，等开销多路径（ECMP）允许多个平行路径可以被使用，基于这个原因，在UDP包源端口内VXLAN封装的entropy也可以被使用。

2.2.3二层单播

二层overlay网络的转发和前面提到的三层overlay网络的转发相同，区别在于

• 路由实例里面的转发表包含MAC地址，而不是IP前缀
• ARP并不用于overlay中（但是用在底层网络）

2.2.4    Fallback Switching

OpenContrail支持混合模式—在虚拟网络中混杂二层和三层的overlay。虚拟路由器中的路由实例同时包含IP FIB和MAC FIB。对于每一个数据包，虚拟路由器先查找IP FIB，如果IP FIB中匹配路由，那么将转发数据包，如果IP FIB中不匹配路由，那么将查找MAC FIB-这就是fallback switching

注意fallback switch“先路由后交换”的行为于IRB（集成路由交换）“先交换后路有的行为”完全相反。

2.2.5  三层组播

OpenContrail支持三层overlay的IP组播，组播操作将通过overlay的组播树和底层网络的组播树来实现，任何一种方式，组播树都可以是共享树（*.G）或者详细源树（S,G）

2.2.5.1  overlay 组播树

OpenContrail支持组播部署使用overlay中的组播树取代底层网络的组播树，详细描述可在[draft-marques-l3vpn-mcast-edge]中，这里我们只汇总一些基本概念

图15描述了在overlay中创建组播树的基本概念。作为组播树的root的虚拟路由器发送N个复制流量到N个下行虚拟路由器，下行路由器在发送N个复制流量给更多的虚拟路由器，进而，知道所有的接受路由器全部覆盖，这个案例中N等于2，数字N并不等于每一个虚拟路由器

系统使用XMPP信令在每个虚拟网络中的虚拟路由器建立FIB，创建overlay的组播树，协议比较复杂，详细描述请参考[draft-marques-l3vpn-mcast-edge]

入口复制，如图16所示，通常是用于常规的overlay组播树的一些陈旧案例中，从实践上来说，入口复制的信令要比常见overlay组播树要更简单一些

2.2.5.2 底层组播复制树

组播实现的另外一个替代方案是在底层使用组播树，如图17所示

这个和通常在MPLS VPN中部署组播比较接近（参见 RFC6513），同样，VXLAN中泛洪并转发控制平面（描述在 [draft-mahalingam-dutt-dcops-vxlan] ），也依赖于底层的组播树

底层组播树是使用组播地址建立GRE通道，这就暗示着底层网络必须要支持IP组播，必须运行一个组播路由协议例如PIM协议，并且必须为每个组播树提供一个组播租

2.2.5.3  对比

对于底层网络的交换机使用组播树，支持IP组播，在实践上会出现一些问题，主要包括

• 尽管底层网络支持组播，运维人员不希望开启组播带来管理和排错的复杂性
• 基于商用芯片的交换机，往往在转发平面支持比较相对有限的组播租，对于组播的最优部署，需要底层网络为overlay网络每一个租户的每一个组提供组播地址，这就需要大量的组播租。当然，使用为每个虚拟网络单一共享树可以减少底层网络的组播租，但是这又带来可优化的开销，并增加的复杂性，
• 在底层运行组播，数据中心交换机在控制平面上维护每一个组接受者的状态，这些状态信息会异常巨大。
• 组播控制平面协议会带来CPU的密集操作，因为组播树需要在接受者加入或离开时时刻更新。

从另一个方面来说，overlay的组播树也会带来产生影响，但是

• 第一个问题，组播复制同样的数据包跨越相同的物理链路，尤其是靠近源端的链路，这样会消耗带宽，但是和广域网不同，对于数据中心网络，这并不是一个大问题，因为数据中心矩阵而言，所提供的是一个CLOS架构的矩阵，可以提供任意点无阻塞的连接。
• 第二个问题是overlay组播树将组播实现的功能在软件虚拟路由器上实现，也会带来CPU的影响，底层网络的硬件交换机通常使用硬件支持组播实现，这个问题可以如图15所示，通过多个虚拟路由器级联的方式实现组播复制，来得以缓解。

2.2.6  Layer 2 BUM Traffic

二层广播，未知单播和组播流量需要在二层网络中泛洪，在OpenContrail中，未知淡泊流量会被丢弃，而不是泛洪，因为系统并不是依赖泛洪-学习的机制来建立MAC地址表，取而代之的是，使用控制协议去建立MAC地址表，如果目的地址未知，那意味着可能是系统出现了某些故障。二层广播也同样避免，因为大部分二层广播都是因为一些协议的操作出现。

对于其他已知的二层广播和组播，系统为每一个虚拟网络的创建一个分布树，连接虚拟网络中的所有路由实例，这个树可以由overlay或者底层网络构成。

2.2.7 代理服务

虚拟路由器代理很多类型的流量（从VM发出的），以此避免泛洪。虚拟路由器拦截特定的数据包，并把这些流量通过XMPP代理给控制节点，控制节点通过XMPP返回响应

当前系统代理如下类型的流量（其他流量代理会在后续增加）

• DHCP请求。控制节点会根据VM的配置提供DHCP的响应
• ARP响应。控制节点提供IP和MAC地址的对应
• DNS和MDNS请求，控制平面提供域名和IP地址的对应。

2.2.8   转发策略

虚拟路由器转发平面包含一个流表，提供多个功能—防火墙策略，负载均衡，汇总等。流表包含流表条目，包含匹配条件的关联的操作，匹配田间可以是接收数据包N元组的匹配（可能是掩码匹配），操作包括数据包的丢弃，允许，或者重定向到另外一个路由实例。流表条目通过虚拟路由器代理在转发平面上形成。

当流表中没有相应条目时，会把数据包挂起，并转发给虚拟路由器代理，这样可以让虚拟路由器识别是否是一个新的流的首包，虚拟路由器代理会为每一个新流创建流表，并把首包发送到转发平面。

OpenContrail支持高级策略语言，允许虚拟网络基于策略互联，这个策略语言类似于Snort规则语言，但是在系统上做了改变和扩展，策略规则如类似于

这个规则允许所有的流量，从虚拟网络src-vn到虚拟网络dst-vn，并且强制流量经由服务链，先经过服务svc-1，然后到svc-2，在前面的案例中，规则允许虚拟网络src-vn的任何虚拟机发送流量到虚拟网络dst-vn的任何虚拟机。

系统考虑流量的引导，将流量使用虚拟接口注入到正确的虚拟机中，这些（负责服务的）虚拟机可以提供诸如防火墙，DPI，IDS，IPS，缓存等网络服务

系统为租户虚拟机增加新的路由实例，为负责服务的虚拟机创建路由实例，流量被引导

• 通过操纵路由的route target（RT）影响从一个路由实例到另外一个路由实例的注入和导出
• 通过操纵下一条和（或者）路由的标签，使得他们可以把路由实例的路由相互泄漏，强制流量按照正确的顺序在路由实例中转发，流量经由正确的虚拟机。

图18描述了服务链中流量在路由实例中转发的基本概念

在上面的案例中

• 通过路由实例中的RT（route target）的注入和导出，使得路由泄漏可以从ri-t2到ri-s2，然后泄漏到ri-s1，再到ri-t1
• 当负责服务的路由实例导出路由时，他们将自己指定为下一跳，并且产生一个新的label。
  • 下一跳引导流量到服务器（也就是服务虚拟机所在物理服务器）
  • 标签引导流量到该物理服务器上的负责服务的虚拟机上

IETF draft[draft-rfernando-virt-topo-bgp-vpn] 描述了服务链的类似机制

2.4.1  IF-MAP

The Interface for Metadata Access Points (IF-MAP) ^[if-map] 是一个开放标准的客户端/服务器协议，由Trusted Computer Group (TCG)开发，作为Trusted Network Connect (TNC)开放架构的核心协议。

原始的IF-MAP应用提供一个Metadata Access Point (MAPs)的通用接口，数据库服务器扮演票据交易所的角色，负责TNC架构中的安全事件，组件和其他内容的信息

IF-MAP提供一个定义数据模型的扩展机制，同时也定义了一个协议，用于发布，订阅，数据存储的查询。

OpenContrail使用IF-MAP协议从配置节点到控制节点分发信息。控制节点可以使用订阅机制，仅仅接受他们感兴趣的配置信息的子集。系统同时使用IF-MAP定义高层级和低层级配置数据模型。

2.4.2  XMPP

The Extensible Messaging and Presence Protocol (XMPP) ^[xmpp] 是一个用于信息导向的中间件，基于XML的通讯协议。XMPP原来叫Jabber，用于即时信息，出席信息和联系列表维护，其设计具有扩展性，协议已经进化成通用的发布订阅信息总线，可以用在多种应用中。

OpenContrail使用XMPP作为一个计算节点和控制节点之间交换大量例如路由，配置，运行状态，统计，日志和事件的通用信息总线

IETF drafts [draft-ietf-l3vpn-end-system] 和 [draft-marques-l3vpn-mcast-edge] 描述了 XMPP 和信息格式

2.4.3  BGP

OpenContrail使用BGP在控制节点之间交换路由信息。BGP也被应用在控制节点和网关节点（大多数网络厂商路由器和交换机）交换路由信息。

2.4.4  Sandesh

Sandesh是一个基于XML的协议，用于汇报分析信息。XML信息的结构被描述成公共语法格式。每个节点的组件都有一个Sandesh连接到分析节点之一上。Sandesh携带两类信息

• 系统的所有组件发送异步协议到分析节点上，汇报日志，监控，事件等
• 分析节点可以发送请求信息和接收响应信息去收集特定的运行状态。

图19描述了OpenStack Nova, Neutron 和 OpenContrail之间的集成。

OpenStack的Nova模型通过计算节点中的Nove 代理创建虚拟机。Nova代理和OpenContrail Neutron插件通讯，检索新的虚拟机的网络属性（如IP地址），当虚拟机创建，Nova代理通知虚拟路由器代理为新创建的虚拟机创建虚拟网络

所有的控制平面协议使用Transport Layer Security (TLS) 和  Secure Sockets Layer (SSL)提供验证和数据完整性，也可以用于提供数据的私密性，尽管这并不在数据中心的考虑之内。

初始化服务查找证书用于验证，后续的通讯都是基于令牌的验证，用以提高性能。服务查询服务器通过证书验证TLS连接在服务器和客户端之间产生令牌证书的分发超出了本文档的范围，从实践上说，这部分工作由服务管理系统例如puppet或者chef来负责。

所有系统内的REST API使用基于策略的授权，服务器通过TLS验证识别客户端，并且指派一个或者多个规则。规则定义客户端的接口操作（只读或者读取）和哪些数据模型的组件客户端可以访问。

2.7.1  配置节点

目前，所有的控制都包含整个系统的运行状态，例如，所有虚拟网络中所有虚拟机的路由，控制状态的总数相比较而言较少，更适合每个配置节点的内存占用。当更多的功能加入之后，控制节点之间控制状态的汇总和分片将会在未来引入，原理类似于BGP中的RT特定路由反射。

每个虚拟路由器代理连接两个或者多个节点，所有的节点都是A-A状态，虚拟路由器代理从每个控制节点接受所有的状态（路由，路由实例的配置等），从两个或者多个节点接受到的状态保证最终一直，但是有可能短暂的不一致。每个虚拟路由器代理执行本地选择，选择使用哪一个控制状态的副本。这类似于BGP PE路由器接受到相同路由（从每一个BGP邻居）的拷贝但是执行本地的最优路径选择。

当一个控制节点失效，虚拟路由器代理将会通知到这个控制节点的连接已经丢失，将会刷新所有从这个失效控制节点接收的状态信息。因为已经有了从其他控制节点的所有信息的状态，虚拟路由器可以本地迅速进行切换，而不需要重新同步，虚拟路由器代理将会再次联系服务查询服务器，和一个新的控制节点建立连接，取代失效的控制节点。

2.7.2   配置节点

配置节点保存所有配置状态在一个可容错，高可用性的NoSQL数据库中，包含高层级数据模型的内容，如预留系统明确安装的配置状态，同时也包括低层级数据模型的内容，例如通过转换模型从高层级数据模型导出的配置状态

控制节点使用IF-MAP订阅控制平面需要的低层级数据模型的部分。服务查找服务器指定每一个控制节点到特定的配置节点。如果配置服务器失效，控制节点重新联系服务查找服务器指定另一个配置服务器、

切换之后，控制节点重新和新的配置节点同步，这类似于路由协议中平滑重启达到的目的—保证所有状态，完整回复并且刷新已有状态信息。