OpenContrail architecture document

2015年1月19日 (一) 05:14的最后版本

OpenContrail 体系架构文档

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

翻译者：@KkBLuE知行合一 其微信号：kkbluepublic，中文版转自：SDNAP.com - SDN联合播报。

[编辑] 概述

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

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

[编辑] 1.1 使用案例

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

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

[编辑] 1.2 OpenContrail 控制器和虚拟路由器

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

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

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

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

[编辑] 1.3 虚拟网络

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

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

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

[编辑] 1.4 Overlay Networking

虚拟网络也可以使用在两个网络中—物理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上的虚拟机内部，或者之间的通讯，会保存路由表，转发表等

[编辑] 1.5 基于MPLS L3VPNs 和 EVPNs的overlay架构

厂商和标准化组织已经提出了真对于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协议非常类似，这样做存在诸多好处：这些协议比较成熟，而且易于扩展，被广泛应用在生产网络，并被多个厂商产品支持，可以无缝互操作，而无需软件网关（译者注：最后一句话实际上是重点，使用老技术来保证新部署模式不需要更新硬件设备）

[编辑] 1.6 Source—OPENCONTRAIL和开源

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

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

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

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

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

[编辑] 1.7 Scale-Out Architecture and High Availability

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

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

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

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

[编辑] 1.8 数据模型核心规则：SDN即是编译器

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

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

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

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

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

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

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

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

[编辑] 1.9 北向API接口

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

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

[编辑] 1.10 图形化用户接口

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

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

[编辑] 1.11 可扩展平台

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

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

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

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

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

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

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

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

转换引擎可以为映射现在的高级服务组件到新的低层级技术组件（实现当前业务的新的方式或者新的网络技术），或者映射新的服务组建到新的或者现有的低层级技术组件（例如部署新服务）进行扩展。 新的南向协议可以引入到控制节点中，这主要用于支持网络中使用不同协议的新类型的物理或者虚拟设备。例如特定厂商的网络设备使用的CLI命令行接口可以被引入，或者可能因为需要部署新的协议，新的组件需要引入到低层级技术数据层面中。

[编辑] 2 OpenContrail系统结构细节

[编辑] 3 数据模型

[编辑] 4 OpenContrail使用案例