OpenVirteX体系结构

综述

《OpenVirteX体系结构》分成三个主要部分。第一部分，介绍：OVX网络虚拟化的快速概述，以及OVX如何通过网络表达呈现给租户以实现高级视图。第二部分，组件：OVX建立其网络所使用的各种抽象表示的细节。第三部分，操作和子系统：描述OVX功能性子系统和通过操作第二部分所介绍的组件来虚拟化网络的特性。

文档中使用一些约定，包括：文件名使用粗体字体，方法和变量使用等宽字体，显示包名称使用方括号。

最后，目标受众应该熟悉SDN架构、OpenFlow协议和Java。我们也建议受众可以得到OpenVirteX的源码，他们能够帮助理解文档。

目录

I． 综述
1.1 网络虚拟化
1.2 OpenVirteX：一个高级视图

II． 组件
2.1 概述
2.2 组件状态机
2.3 组件持久性
2.4 交换机（Switches）
2.5 端口（Ports）
2.6 链路和路由（Links and Routes）
2.7 地址（Addresses）
2.8 主机（Hosts）
2.9 网络拓扑
2.10 全局共享映射（Shared Global Mappings）
2.11 信息（Messages）

III． 操作与子系统
3.1 系统概述
3.2 启动与关闭
3.3 事件循环
3.4 网络发现
3.5 虚拟化与去虚拟化
3.6 状态同步
3.7 弹性
3.8 持续性
3.9 JSONRPC API

1 概要

本节概述了OpenVirteX网络虚拟化的定义，从OVX虚拟化网络的高级视图开始。
1.1 网络虚拟化
1.2 OpenVirteX：一个高级视图

1.1 网络虚拟化

网络虚拟化允许多个租户占据相同的网络基础设施，每个租户会有一种错觉，认为可以对整个网络进行完整的处理。OVX通过给每个租户提供访问一个虚拟网络拓扑和一个完整的网络头空间来达到这样的目标，前者允许租户自定义拓扑结构,而后者保证功能性和流量隔离，即使是在不同的租户选择重叠的寻址方案。

在拥有类似能力的网络中，允许多个租户共存，这不同于网络切分（network slicing），网络切分是在所有租户分离某一单独头空间的部分。例如,两个租户在自己的虚拟网络可以使用相同的IP子网和TCP / UDP端口,而在两个网络切片中,这将切片之间的流量泄漏。另一个区别是在可能的拓扑结构上。虚拟网络不需要对应于底层网络的拓扑结构，然而网络切片必须被限制为原来网络的同构子图。

OVX通过作为代理来实现网络虚拟化。代理位于网络和租户网络操作系统之间。对于每一个租户，OVX重写OpenFlow消息用于翻译租户网络操作系统（NOS）发送给它的虚拟网络的消息及从虚拟网络接收到的消息，决定物理网络收到后应该产生与租户网络一致的行为。这样的方法会产生两个后果:

· 允许OVX呈现支持OpenFlow的可编程虚拟网络，租户可以使用自己的NOS控制虚拟网络

· 使OVX是透明的——从底层网络的角度，OVX的表现为一个控制器，从租户的角度上看，OVX作为网络中具有OpenFlow能力的交换机集合。

由于这部分的功能，OVX作为租户控制平面与基础物理设施之间OpenFlow消息的多路复用器/解复用器。特别的，这个过程依赖于这样的一个假设：每个网络主机属于一个虚拟网络。主机硬件地址在关联租户与他们的网络流量中发挥关键作用。

图1.1展示通过OVX支持三个租户的网络虚拟化。

                                                                         

图1.1：OVX网络虚拟化。每个租户可以部署自己的控制平面来管理OVX呈现给它们的虚拟网络

最后，OVX在OpenFlow消息到达租户NOS之前重写该消息（也就是虚拟化网络）的方式使其成为网络衬底（underlay）。这是相对于NOS给其应用提供虚拟化能力的网络覆盖（overlay）来说的。

1.2 OpenVirteX：一个高级视图

OVX保持对每个租户虚拟网络和物理网络的逻辑表示。OVX通过拓扑发现建立物理网络基础设施的视图，通过OVX API提供的配置信息建立虚拟网络的视图表示。

如下图1.2所示，OVX限制物理网络与虚拟网络的耦合：1）一些共享的全局结构存储物理网络元素与虚拟网络元素之间映射2）在消息事件循环中的虚拟化/去虚拟化例程重写和/复用/解复用在控制信道中的消息。控制信道被分为两种：

·        在租户控制器和OVX北向接口部分之间的虚拟部分（图中用蓝色表示）

·        在网络和OVX南向接口部分之间的物理部分（图中用橙色表示）

耦合点用于物理环境与虚拟环境之间的转换，物理环境和虚拟环境是跨控制信道的。因为物理和虚拟这两个部分逻辑上是去耦的，所以OVX本身能够建立和保持与数据路径（datapath）的连接，即使是在没有虚拟网络和连接到租户控制器存在的情况下。

图1.2：（左图）在OVX中，物理网络（黄色）和租户网络（蓝色）的表示在逻辑上是分离的，租户1和租户2仅可以“看到”OVX呈现给他们分别标记为vnet1和vnet2的虚拟拓扑。vnet1、vnet2的拓扑，和他们与物理网络之间的映射通过API调用来配置，并且存储在全局映射（绿色）。映射中的内容可以从物理和虚拟网络进行访问（橙色和蓝色线）（右图）。物理 - 虚拟分割是由OpenFlow消息虚拟化/去虚拟化过程处理的，在这个过程中引用了全局映射。

3.5节提供了一个详细讨论关于如何实现OVX分隔通道。

我们现在进入第二部分来看看OVX用来表示物理和虚拟网络的部件和结构，并且是如何在物理和虚拟网络之间映射和转换的。

2 组件

概要

本节描述OVX所使用的代表各种网络元素和OpenFlow消息的类和包。

2.1 概述
2.2 组件状态机
2.3 组件持久性
2.4 交换机（Switches）
2.5 端口（Ports）
2.6 链路和路由（Links and Routes）
2.7 地址（Addresses）
2.8 主机（Hosts）
2.9 网络拓扑
2.10 全局共享映射（Shared GlobalMappings）
2.11 信息（Messages）

2.1 概述

OVX的网络表示，无论是物理的还是虚拟的，均是交换机、端口、链路、主机和地址对象的集合。对于一个租户来说，这些组件与实际的数据路径（datapath）、端口、链路、主机相比并不会表现出什么差异。在上一节中所描述的全局映射在虚拟组件对象和物理组件对象之间建立了一个N对1的映射，用于将租户拓扑映射到基础设施上。

为了减少基础设施和OVX对象的混淆，在文档中，我们遵循以下几个约定：

·        “基础设施”是指运营商或供应商的实际网络。

·        “路径”（datapath）一般在提及基础设施使用，与“交换机”（switch）可互换使用。

·        “网络”本身指的是基础设施建设，OVX中以“物理网络”和“虚拟网络”来表示。

·        任何像交换机和链路这样的资源均是OVX的结构。

·        “租户控制器”，“控制器”，“网络操作系统”和“NOS”是可互换使用的。

2.1.1 实现类（Implementing Classes）        

OVX由Java语言实现。这些组件被定义为包中的类，在[net.onrc.openvirtex.elements.*]下，每个组件是由一个基类定义。基类如下表所示：

这些类派生出子类来实现物理和虚拟版本的每个组件，当前的组件类和他们的父类如下表所示：

例如，“PhysicalPort”是网络交换机的端口，“OVXSwitch”提出的是OVX提供给租户的一个虚拟交换机。为了方便，大多数表示基础设施的组件名称以“Physical”开头，代表租户网络的组件以“OVX”开头。值得注意的是，Host只有虚拟表示形式。

OVX通过创建一个PhysicalNetwork实例来建立物理网络的声明。该PhysicalNetwork实例由交换机、链路和端口对象填充创建，通过各种网络发现技术，使得他们在基础物理设施中被发现。虚拟网络表示或OVXNetwork实例通过调用创建网络对象的API来建立，并且可将它们映射到物理网络组件。网络发现和JSONRPCAPI分别在3.4和3.9节介绍。

2.2 组件状态机

网络元素与多个状态均有关，这些状态与其他元素的状态相互依赖。例如，如果网络中的一台交换机关机，它的全部端口和这些端口连接的链路也将失效，网络拓扑结构的改变将被OVX所感知。

为了允许OVX追踪和描述这些组件的状态和它们是怎样交互的，组件类实现有限状态机（FSM），状态的转移是依据其他状态所触发的，FSM驱动是由隐式依赖图所决定的。

本部分将介绍这些状态。

2.2.1基本FSM状态

除了Address类和OVXSwitch子类，每个组件类目前处理四个状态：

·        INIT：刚刚创建，也就是说，它的构造器刚被调用

·        INACTIVE：惰性的网络事件，也就是OpenFlow消息和网络发现

·        ACTIVE：正常操作状态，所有事件处理像预期的那样进行

·        STOPPED：毁坏，必须重新创建对象才可以再次使用

例如，管理端口禁用状态是INACTIVE，操作者将OVXSwitch从网络中移除后为STOPPED。

有限状态机现在用Java枚举来实现。选择这种方法是由于这样较易于修改—如果需要一个新状态，我们仅是简单地添加另一个状态和一些默认行为到FSM，有限状态机的每个组件类被命名为State，例如，PhysicalSwitch和OVXSwitch的有限状态机被表示为SwitchState。

2.2.2组件FSM接口

FSM组件类继承于Component接口，该接口定义了一些状态转移的方法，为了统一，每个方法与一系列动作相关联，使得可以对一个组件进行函数化的状态转移：

·        register() [INIT->INACTIVE]：将组件添加到映射和存储，检查依赖关系（例如，一个新端口在交换机不存在的时候是不可以被创建的）

·        boot() [INACTIVE -> ACTIVE]：打开控制信道，激活相关依赖组件（例如：在两个端口都boot()的状态下建立链路连接）

·        teardown() [ACTIVE -> INACTIVE]：关闭控制信道，关闭相关组件（例如:一个端口被禁用，链接的链路也会被禁用）

·        unregister() [INACTIVE -> STOPPED]：从映射和存储中移除，在必要时关闭或解注册相关组件（例如：链路的连接端口若已处于unregister()状态，那么这一条链路将不再存在，并且也必须处于unregister()）

图2.1总结了一般组件的有限状态机和状态转移的相关方法。每个OVX类衍生自实现类Component和有限状态机（FSM）的某种形式或另一种形式。

图2.1

注意：一个组件只能从INACTIVE状态激活或停止，这样做是为了保证在把某些东西加入网络表示或从网络表示中删除之前相关的依赖关系会得到安全处理。本节讨论如何将组件的有限状态机连接在一起，以实现组件的依赖，并实现网络状态同步。

2.3 组件持续性

虚拟组件是由管理员配置。管理员可能需要在OVX重启过程中持续配置。OVX可在远程数据库中存储配置以用于在OVX重启的系统恢复。

可被存储的组件类实现Persistable，接口类有如下抽象方法：

接口类Persistable定义于[net.onrc.openvirtex.elements]，继承于Persistable类的这些方法涉及到与数据库的序列化/反序列化。具体实现细节会在第三部分介绍。

其余的小节描述包含实现各种元素的类。

2.4 交换机Switches[包net.onrc.openvirtex.elements.datapath]

交换机是一个数据路径的表示，由一组端口、交换机ID(DPID)、功能/属性摘要以及一个通道来描述。

protected booleanisConnected = false; // Channel liveness indication

protectedOVXDescriptionStatistics desc = null; // Switch statistics

// T extends Port.

protectedHashMap<Short, T> portMap //The ports on this switch, keyed by portnumber

protectedOFFeaturesReply featuresReply // The Features Reply

protected LongswitchId // The DPID of the switch

protected Channel channel // Thecontrol channel to the datapath

交换机子类作为OVX和租户NOS（OVXSwitch）之间以及OVX和数据通道（PhysicalSwitch）之间的OpenFlow信道的定位点。到达OVX的所有消息，要么会被北向或南向事件循环直接处理，要么通过特定消息处理方法sendMsg()和handleIO()处理。下面的类继承基类Switch：

PhysicalSwitch (extends Switch)：代表网络中已经连接到OVX的交换机。在OVX与交换机握手期间，PhysicalSwitch的属性由OVX接收到的OpenFlow信息内容来进行填充，在OVX运行期间status信息被接收。PhysicalSwitch保持交换机中发现的流表，并且为OpenFLow XID设置XID转换器，OpenFlow XID用来控制发送到租户控制器或从租户控制器接收到的流量。

组件：

·        StatisticsManager statsMan :相关datapath统计集合

·        AtomicReference<Map<Integer,List>>flowStats :以租户为key建立的流表、流表项

·        AtomicReference<Map<Short, OVXPortStatisticsReply>>portStats :以端口号为key的端口统计

·        XidTranslator translator : XID复用器

·        SwitchState state :物理交换机实例的有限状态机

PhysicalSwitch包含一个内部类SwitchDeregAction，用于同步虚拟元素和它映射的物理元素之间的状态。3.6部分会详细地解释OVX的状态管理。

OVXSwitch (extends Switch)：是OVX虚拟交换机表示的父类，即租户控制器可见的交换机。OVXSwitch实现送到租户FeaturesReply信息，和维护虚拟流表以及通过bufferID进行对PacketIn的缓冲区映射。此外，OVXSwitch能够连接到多个控制器和处理控制器角色。角色管理在3.4节中讨论。

组件：

·        LRULinkedHashMap<Integer, OVXPacketIn> bufferMap

·        Integer tenantId :该交换机所属的租户网络ID

·        OVXFlowTable flowTable :维护交换机流表条目的结构

·        XidTranslator channelMux :信道复用，支持多种NOS连接

·        RoleManager roleMan:角色消息管理

·        SwitchState state : OVXSwitch实例的有限状态机

此外，OVXSwitch直接实现一些OFFeaturesReply字段:

// Note, someattributes of a virtual switch are fixed:

protected staticint supportedActions = 0xFFF; // The supported actions.

protected staticint bufferDimension = 4096; // The buffer dimension.

protected ShortmissSendLen = 128; // The miss send len. Default in spec is 128

protected OVXSwitchCapabilitiescapabilities; // The capabilities.

OVXSwitch的两个子类表示交换机虚拟化的两种模式：

OVXSingleSwitch：在网络中映射到一台交换机的虚拟交换机。

OVXBigSwitch：在网络中映射到多台交换机的一台虚拟交换机，并把这一组交换机作为一个单独的大虚拟交换机（BVS）的”crossbar”，OVXBigSwitch通过它虚拟的“crossbar”来维护路由表。

组件：

·        RoutingAlgorithms alg：计算路径算法，可以手动指定（手动），也可以是最短路径（SPF）。

·        HashMap<OVXPort, HashMap<OVXPort, SwitchRoute>>routeMap：通过BVS的映射，给定入口和出口端口。

图2.2显示在虚拟网络中的3个交换机类。

图2.2：每个PhysicalSwitch（PSW1，2和3）直接映射到一个交换机（交换机1，2和3）中的基础设施。虚拟交换机vsw1是直接映射到PhysicalSwitch PSW1的OVXSingleSwitch实例。vsw2是映射到PSW2和PSW3一个OVXBigSwitch实例，并且使用SwitchRoute作为它们之间的链接。租户网络可以有两种类型OVXSwitch，只要他们不使用相同的PhysicalSwitches即重叠的PhysicalNetwork。最后，交换机实例是OpenFlow信道（蓝色）的终止点。

2.5 端口[package net.onrc.openvirtex.elements.port]

交换机端口作为存储在交换机portMap结构中Port的子实例。端口有部分属性从OpenFlow协议中的ofp_phy_port结构中继承。OVX又加入了如下内容：

// T1 extendsSwitch, T2 extends Link

protectedMACAddress mac // the hardware address of the port

protected BooleanisEdge // true if this port is an edge

protected T1parentSwitch // the switch that this port belongs to

protected LinkPair portLink // if notan edge, the Links to/from this port

关于ofp_phy_port的细节，请查阅OpenFlow协议。标识isEdge为true代表没有链路连接在此端口上。注意，端口有一个state属性，这是ofp_phy_port的一部分，这与端口的有限状态机并没有关系，但这个值会影响到Port子类的有限状态机，在3.6节会说明这个问题。

OVX实现如下两个端口子类：

PhysicalPort(extends Port<PhysicalSwitch,PhysicalLink>)代表物理交换机上的一个端口。端口数和特性可以在交换机的Feature Reply中找到。PhysicalPort保持了它与虚拟端口之间的映射。在租户网络中，物理端口至多映射一个OVXPort。

组件：

·        Map<Integer, HashMap<Integer, OVXPort>> ovxPortMap

·        PortState pstate :端口的状态机

OVXPort(extends Port<OVXSwitch，OVXLink>)是OVXSwich上的一个端口。OVXPorts通过管理配置来实现实例化。

组件：

·        Integer tenantId :该端口OVXSwitch所属网络的租户ID

·        PhysicalPort physicalPort :端口映射到的PhysicalPort

·        PortState pstate :端口状态

2.6 链路和路由[packagenet.onrc.openvirtex.elements.link/net.onrc.openvirtex.routing]

OVX通过链路来表示交换机和端口之间的内部连接。链路被两个终端定义，即源交换机/端口对和目的交换机/端口对：

protected T1 srcPort        // source Port

protected T1 distort        // destination Port

 

// endpoint Switches are fetched from theparentSwitch attributes of the Ports

public T2 getSrcSwitch() {

    return(T2) this.srcPort.getParentSwitch();

}

public T2 getDstSwitch() {

    return(T2) this.dstPort.getParentSwitch();

}

链路是定向的，所以一个pair用于表示一个双向链路，LinkPair以Port为key值。有三个类继承Link类。

PhysicalLink（继承Link<PhysicalPort,PhysicalSwitch>）通过物理端口实现两个物理交换机的互连，并且在网络中进行1：1的链路映射。OVX在运行期间通过拓扑发现来查找物理链路。

组件：

·        Integer linkId：链路的全局唯一ID

·        AtomicInteger linkIds：全局ID计数器，用于linkld产生

·        LinkState state：物理链路的有限状态机

OVXLink（继承Link<OVXPort,OVXSwitch>）在同一租户网络中完成两台OVXSwitch上的两个OVXPort的互连。一个OVXLink可能映射到一条或多条相邻的物理链路。OVXLink由租户配置。

组件：

·        Integer linkId：租户网络中唯一链路ID

·        Integer tenantId：租户网络的唯一ID

·        Mappable map：指向全局映射

·        LinkState state：OVXLink关联的有限状态机

·        RoutingAlgorithms alg：OVXLink映射到一系列PhysicalLink上的方法。当前的两个选项为静态（手动）或最短路径（spf）

SwitchRoute（继承Link<OVXPort,PhysicalSwitch>）在同一个OVXBigSwitch上互连两个OVXPort，定义一个流量路径穿过OVXBigSwitch的crossbar。SwitchRoute可能映射到一个或多个物理链路，并且由两种类型的终端定义。

·        BVS ingress/egress port：OVXPort作为交换机端口被租户识别

·        SwitchRoute endpoints：BVS内部的PhysicalPort

组件：

·        Integer routeId: SwitchRoute ID，用于OVXBigSwith的唯一识别

·        OVXSwitch sw：SwitchRoute所属的交换机

·        RouteState state：SwitchRoute的有限状态机

·        PhysicalPort inPort：SwitchRoute的入端

·        PhysicalPort outPort：SwitchRoute的出端

SwitchRoutes可以由租户指定，或者通过OVXBigSwitch实例的RoutingAlgorithm生成。图2.3和2.4总结了三种链路类型之间的结构与关系。

图2.3：上部）三台物理交换机(ps1,ps2,ps3)通过物理端口（白色圆圈）建立两条物理链路。中部）两台OVXSwitch通过OVXPort（黑色圆圈）建立一条OVXLink。vs1和vs2分别映射到ps1和ps3上。OVXLink映射到两条物理链路，但在租户看来似乎只有一条，ps2不可见。底部）SwitchRoute在同一个BVS内连接两个OVXPort。SwitchRoute有一个外部终端（OVXPort）和内部终端（PhysicalPort）。

图2.4：网络对各种链路的映射。上图为两个租户，其底部为OVX物理网络视图。注意，只有一个PhysicalNetwork，不过为了清晰起见，我们展示了两个实例。左侧）租户1有两条OVXLink，即vlink1和vlink2。vlink1对应路径ps1-ps3-ps2即物理链路l2和l3，然而vlink2是1：1映射到l5上。右侧）租户2包含OVXLinks(红色)和在OVXBigSwitch vs2中端口之间加入的SwitchRoute，后者映射到l3(蓝色)。

2.6.1虚拟链路恢复

虚拟链接(OVXLinks和SwitchRoutes)与一个或多个PhysicalLinks列表相关联。我们称这些列表为路径。虚拟链路的优先级为其主要路径的优先级值。主要路径可以是为虚拟链路设置的唯一路径，或者是最高优先级的路径。当多条路径连接到一条虚拟链路，未使用的路径可以借助如下几个结构用于组件的恢复：

·        private byte priority :虚拟链路的当前优先级

·        private final TreeMap<Byte, List>backupRoutes : 包含可选路径的容器,优先级为key

·        private final TreeMap<Byte, List> unusableRoutes :包含失败路径的容器，优先级为key

关于恢复的细节将在3.8节详细讨论。

2.7 地址(Address)[packagenet.onrc.openvirtex.elements.address]

网络主机的IP地址是格式化的整型，OVX在虚拟化过程中识别两种类型的IP地址：

·        OVXIPAddress是网络主机的IP地址，通过外部方式分配给主机。在租户网络中OVXIPAddress是唯一的。

·        PhysicalIPAddress通过OVX分配并且在全网中唯一。OVXIPAddress在网络中心被映射到PhysicalIPAddress以便识别不同租户的流量。这个过程在3.5节地址虚拟化中介绍。

2.8 主机(Hosts)[packagenet.onrc.openviretex.elements.host]

主机代表穿过租户网络的流量终端。主机通过连接点、地址和唯一ID来定义:

private finalInteger hostId;               //OVX-asigned UUID

private finalMACAddress mac;               // MACaddress of host in the network

private finalOVXPort port;                 //Attachment point

privateOVXIPAddress ipAddress;             //Network address

private HostState state                     // Host FSM

OVX主机是虚拟概念，没有单独的物理和虚拟表示形式。一个主机的物理表示是通过查找其附着点和网络地址的物理同等设备产生的。

publicHashMap<String, Object> convertToPhysical() {

            HashMap<String, Object> map =new HashMap<String, Object>();

    map.put("hostId", this.hostId);

    map.put("dpid", this.port.getPhysicalPort().getParentSwitch().getSwitchName());

 

    // Find Physical attachment point thatcorresponds to Host's virtual one

    map.put("port",port.getPhysicalPortNumber());

    map.put("mac",this.mac.toString());

 

    // Find Host's PhysicalIP, if it has one

    if (this.ipAddress.getIp() != 0)

            try {

                   map.put("ipAddress",OVXMap.getInstance().getPhysicalIP(this.ipAddress,this.port.getTenantId()).toSimpleString());

...

注意：OVXPort的isEdge属性为true表示这是主机连接点。

2.9 网络[packagenet.onrc.openvirtex.elements.network]

Network类存储了描述整个网络中交换机、链路、端口和主机关系的映射：

protected finalSet<T1> switchSet;                 // set of all switches found in this network

protected finalSet<T3> linkSet;                   // set of all links within this network

protected finalMap<Long, T1> dpidMap;             // mapping between switches and their DPIDs

protected finalMap<T2, T2> neighborPortMap;       // mapping between ports that are endpoints of the same link

protected final Map<T1, HashSet<T1>>neighborMap;   // mapping between aswitch and its adjacencies

网络不记录SwitchRoute或者哪个端口属于哪个交换机，因为它们存在于Switch类中。目前有派生自网络类的两种网络表示：

PhysicalNetwork是代表OVX网络视图的单例类，理论上，PhysicalNetwork是基础设施及其状态的准确完整拷贝。PhysicalNetwork在每台交换机上保持基于LLDP的拓扑发现，并且HasedWheelTimer驱动拓扑发现和统计收集过程，网络拓扑发现的详细过程请见3.4节。

组件：

·        PhysicalNetwork instance : PhysicalNetwork的单例

·        ArrayList uplinkList :

·        ConcurrentHashMap<Long,SwitchDiscoveryManager>discoveryManager :交换机(DPID)和拓扑/端口状态发现管理之间的映射

·        HashedWheelTimer timer :部署周期任务定时器

·        NetworkState state :物理网络的有限状态机

OVXNetwork是呈现给租户的网络表示，OVX为每个租户维护一个OVXNetwork实例，该实例通过一个唯一的租户ID标识，并映射到PhysicalNetwork。虚拟网络的拓扑通过OVX的API来配置。OVXNetwork实例为其组件维护一个唯一标识，以及主机之间流量的标识。

组件：

·        Integer tenantId :租户网络的唯一ID

·        HashSet controllerUrls :租户控制器

·        IPAddress network :租户使用的网络地址块

·        short mask :租户使用的网络掩码

·        HashMap<IPAddress, MACAddress> gwsMap :

·        BitSetIndex dpidCounter, linkCounter, ipCounter, hostCounter :DPID，链路 ID，IP地址和主机ID的生成器

·        Map<OVXPort, Host> hostMap :虚拟网络中主机与它们连接点之间的映射。

·        OVXFlowManager flowManager : 追踪以太网源地址到目的地址之间的流

·        NetworkState state : OVXNetwork的有限状态机

2.10 全局共享映射:[package net.onrc.openvirtex.elements]，ovxPortMap

物理网络和租户网络之间的映射存储在全局可访问的、单例OVXMap结构中，映射接口定义了可用的方法来操作这些映射关系。 OVXMap包含一系列以网络组件或其标识符为key值的Java映射集合。

除OVXMap之外，PhysicalPort的ovxPortMap直接在PhysicalPort实例中存储OVXPorts到PhysicalPort的映射。

2.11 消息(Messages)[packagenet.onrc.openvirtex.messages]

OVX将OpenFlow消息作为特定的消息类实例来处理，每个OpenFlow消息[org.openflow.protocol]都对应一个OVX等价类，也就是说，类名以‘OVX’开头，代替‘OF’，这些消息类实现以下任一种接口：

·        Virtualizable(public void virtualize(Pyhsical Switchsw))：处理物理交换机sw的datapath收到的租户层面消息。这涉及到决定哪些租户应该接收消息，每个租户应该如何重写消息以与租户的OVXNetwork拓扑进行通信。

·        Devirtualizable(public void devirtualize(OVXSwitchsw))：处理被租户控制器重写至OVXSwitch的网络层面消息。这涉及到决定消息被应用到哪个datapath，并重写消息内容以适应网络的内容。

1.2节中的图1.2对此接口进行了详细阐述，3.3节描述了触发这些方法的核心事件轮询机制，3.5节描述了(de)virtualization 过程。

3 操作与子系统

这一部分描述了OpenVirteX和它诸多子系统的内部工作原理。这些子系统允许OVX操作第两部分所描述的组件以用来实现OpenFlow网络的虚拟化。

3.1 系统概述
3.2 启动与关闭
3.3 事件循环
3.4 网络发现
3.5 虚拟化与去虚拟化
3.6 状态同步
3.7 弹性
3.8 持续性
3.9 JSONRPC API

3.1 系统概述

OVX被分为如下几个主要部分：

·        面向网络的南向接口：用于建立和维持基础设施（PhysicalNetwork），管理OVX和数据路径（datapath）之间的OpenFlow信道。

·        面对租户的北向接口：呈现由软件交换机（OVXSwitches）和虚拟链路（OVXLinks）构成的虚拟网络中的每个租户，管理OVXSwitches和租户控制器之间的OpenFlow信道。

·        全局映射Globalmap（OVXMap，PhysicalPort.ovxPortMap）：完成虚拟网络和物理网络之间的相互映射，并且连接这两个网络。

·        API server：监听JSONRPC调用系统配置和系统/网络状态信息。

Global mapping在创建OVXNetwork时完成，虚拟网络和物理网络的信道管理在分离的IO循环中完成。对于每个消息，循环会做如下处理：1）有一个源或目的OVXNetwork；2）必须穿过北向南向分界，也就是必须调用virtualize()和devirtualize()方法。 OVX南北向接口的这种默认解耦状态使在运行时期动态重配置OVXNetwork成为了可能，可通过API调用来操纵全局映射，并且允许OVX保留到网络的连接即使在租户不存在的情况下。

第3部分主要描述子系统和机制，使得OVX可通过函数调用的方式来创建隔离的虚拟OpenFlow网络。

3.2 启动和关闭

这个部分描述了OVX的启动和关闭过程。

3.2.1主进程启动

OVX的main函数在OpenVirtex.java[package net.onrc.openvirtex.core]中。main函数解析系统设置的命令行参数，并且启动OpenVirteXController，OpenVirteXController实现OVX的可运行状态，记录如下系统配置信息：

·        系统配置文件路径（目前OVX还未使用）

·        OVX南向接口监听OpenFlow连接的主机和端口

·        OVX持续性存储应该连接的主机和端口

·        工作线程的最大数量

·        租户网络的最大数量

·        轮询PhysicalNetWork的统计数据率

对于完整列表，请查看OpenVirteXcontroller类的构造器或者是OVX的帮助函数。

为了初始化这些设置，OpenVirteXController，按如下顺序：

1. 初始化单个PhysicalNetwork实例
2. 尝试连接数据库（database）来恢复原先的虚拟网络配置（如果存在的话）
3. 开启API server
4. 初始化北向信道处理程序

OVX在第3步监听API调用，在第4步与datapath连接，这时我们认为OVX已经初始化。

3.2.2PhysicalNetwork部署/南向信道初始化

随着交换机连接到OVX，二者之间的链路被发现，PhysicalNetwork结构也被部署。在per-datapath的基础上OVX初始化网络拓扑发现，per-datapath为每个交换机创建了PhysicalSwitch类和SwitchDiscoveryManger类的一个实例。先前提到，从交换机的角度，OVX更像是一个控制器。因此，在OVX作为控制器时，连接的建立遵循OpenFlow握手的过程。图3.1展示了交换机的状态机。

图3.1南向接口与datapath握手的状态机，OVX作为控制器

SwitchChannelHandler[net.onrc.openvirtex.core.io]在ChannelState枚举中实现该状态机。每个ChannelState值代表datapath可到达的状态，并且定义了特定状态消息的处理方法。ChannelState也定义了一个默认的行为，但特定状态方法重写了这个行为无论datapath是否处于特定状态。

OVX仅在datapath到达WAIT_DESCPRIPTION_STAT_REPLY状态时将datapath映射到PhysicalSwitch上。OVX在握手期间通过datapath提供的信息配置PhysicalSwitch，并且将PhysicalSwitch加入PhysicalNetwork。一旦SwitchDiscoveryManger映射到它的PhysicalSwitch,并且PhysicalSwitch的StatisticsManger可用，这时datapath被认为处于ACTIVE状态。一个处于ACTIVE状态的物理交换机将参与网络发现和事件循环。状态和拓扑发现的细节将在3.4节讨论，事件循环将在3.3节讨论。

3.2.3租户网络（OVXNetwork）/北向信道初始化

租户网络通过API调用来实现创建、配置和初始化。

OVX网络的创建按照如下步骤：
1. 声明OVXNetwork，使用的地址块，连接到OVX的租户控制器
2. 从可用的物理交换机中创建OVXSwitch
3. 向OVXSwitch添加虚拟端口（OVXPorts）
4. 添加虚拟链路（OVXLinks）、主机（Hosts）、BVSes，交换路由（SwitchRoutes）
5. 如果使用手动配置，为OVXLink和SwitchRoute指定路径
6. 为OVXLink和SwitchRoute添加备份路径（可选）
7. 初始化OVXNetwork

在内部，这些命令促使OVX完成：
1. 实例化虚拟组件
2. 在全局映射中将虚拟组件映射到PhysicalNetwork组件上
3. 让虚拟组件到达ACTIVE状态，依照依赖顺序，启动OVXNetwork

第一个列表中的步骤需要调用一个或多个API[net.onrc.openvirtex.api.server],这些调用由租户处理程序（tenant handles[api.server.handlers.tenant]）处理。表1显示了用于映射的租户处理、实例化的虚拟元素和参数：

注意，创建虚拟组件和路径，需要了解可用的物理组件和网络拓扑结构。还要注意，上面的表格是不完整的API处理程序列表，仅仅列出了在OVXNetwork初始化中发挥作用的元素。本章提供了一个完整的API调用及其语法列表，在3.9节会详细介绍API服务器。

图3.2展示了第二个列表中第三步初始化OVXNetwork的过程。

图3.2租户网络的启动过程，通过调用API服务器开始

如前所述，每个用于实现组件接口的类均包含register()和boot()方法来完成部分初始化过程。需要注意的是初始化遵循一定的顺序，首先初始化的组件状态将影响随后初始化的组件。OVX各种对象之间的状态依赖关系见图3.3。

图3.3：OVX组件依赖关系图。箭头方向表示“影响...的状态”的关系，反向箭头表示“影响...的映射”关系。例如，移除一个OVXPort，意味着任何OVXLinks、主机和连接到该端口的SwitchRoutes被删除。相应地，OVXSwitch必须从portMap中删除该端口，OVXNetwork必须从链路集合删除任何已经被删除的OVXLinks。黑色箭头表示限于任何物理或虚拟部分的查询，绿色虚线箭头表示物理到虚拟的直接依赖。当在谈论内部状态同步时我们还会重提图3.3。

ControllerChannelHandler[net.onrc.openvirtex.core.io]实现了租户控制器与OVXSwitch实例握手的状态机，如图3.4中所示。

图3.4控制器状态机，从OVX作为datapath的角度上看

3.2.4系统关闭

关机通过OpenVirtexShutdownHook[net.onrc.openvirtex.core.io]来实现，它调用了
OpenVirteXController.terminate方法来处理。此方法关闭网络和租户面向的信道，注销该PhysicalNetwork（即已停止状态），并从其数据库断开与OVX连接。考虑到PhysicalNetwork已经部署，并且OVXNetworks存在时，关机过程需要按照图3.3中依赖关系图规定的顺序依次销毁。

3.3 事件循环

本节对核心I/O循环操作进行概述。

3.3.1 概述

OVX事件循环进行OpenFlow消息的处理。事件循环的主要角色是：

·        完成datapath和租户控制器的OpenFlow握手（初始化）：如前所述，OVX实现控制器端和交换机端的OpenFlow握手来建立OVX与datapath、OVX与租户控制器之间的控制信道。

·        OpenFlow消息的虚拟化与去虚拟化：对于每个OpenFlow消息都必须跨物理-虚拟区域，OVX必须能够正确查找其必须写入的控制器通道，并在有必要时，重写该消息域以保持不同租户网络视图的一致性。OVX也可以通过查找接收到网络侧消息的datapath，重写消息，以及解决租户头空间之间的重叠，来逆转这个过程。重写消息不仅保证与PhysicalNetwork网络视图一致，也可使租户之间的流量隔离。

·        处理到/从数据通路（datapath）和控制器的keep－alives消息：datapath和控制器在空闲时交换echo request/reply消息。OVX在单一通道上处理这些消息。

事件循环当前的实现依赖于网络的异步I/O和Java执行的线程池。这是处理API调用的一个单独的循环。

3.3.2消息处理与虚拟化（去虚拟化）

OVXMessage实现了如下一个或两个接口：
虚拟化：virtualize(PhysicalSwitch sw)：控制器侧消息
去虚拟化：devirtualize(OVXSwitch sw)：网络侧消息

这些接口方法的参数均为已从各自信道上接收到消息的交换机实例。不跨虚拟与物理分界的消息，如握手消息与keep－alives(OVXEchoRequestReply)消息并没有virtualize()和devirtualize()方法 。穿过分界的消息依次在各自的devirtualize()和virtualize()方法中实现虚拟到物理和物理到虚拟的转化过程。

这些方法被handleIO()调用，交换机抽象方法在PhysicalSwitch和OVXSwitch中实现。

@Override

public voidhandleIO(OFMessage msg, Channel channel) {

    this.state.handleIO(this, msg, channel);

}

OVXMessage方法实际的调用发生在物理交换机与虚拟交换机的有限状态机处于ACTIVE的状态时：

PhysicalSwitch.Switchstate.ACTIVE:

public voidhandleIO(PhysicalSwitch psw, final OFMessage msg, Channel ch) {

    try {

        ((Virtualizable) msg).virtualize(psw);

    } catch (final ClassCastException e) {

    psw.log.error("Received illegal message: " + msg);

    }

}

OVXSwitch.Switchstate.ACTIVE:

public voidhandleIO(OVXSwitch vsw, final OFMessage msg, Channel ch) {

    /*

     * Save the channel the msg came in on

     */

   msg.setXid(vsw.channelMux.translate(msg.getXid(), ch));

    try {

        /*

         * Check whether this channel (ie.controller) is permitted

         * to send this msg to the dataplane

         */

 

        if (vsw.roleMan.canSend(ch, msg) )

            ((Devirtualizable)msg).devirtualize(vsw);

        else

            vsw.denyAccess(ch, msg,vsw.roleMan.getRole(ch));

    } catch (final ClassCastException e) {

        OVXSwitch.log.error("Receivedillegal message : " + msg);

    }

}

FSM的默认行为是发出警告和丢弃消息。

图3.5总结了事件循环的高级视图。

图3.5：核心OVX事件循环，显示了通过OVX的主要消息处理路径。蓝色、绿色、橙色块在逻辑上分别表示虚拟、全局和物理组件。灰色的步骤出现在SwitchChannelHandler（橙色区域）和ControllerChannelHandler（蓝色区域）。蓝色箭头表示OpenFlow信道。

每个消息具体如何被virtualize()或devirtualize()处理取决于各自的OvxMessage类如何定义这些方法。此处我们不会涉及到每一个消息，但当出现特定的消息时再做集中讨论。

3.4 网络发现与呈现

为完成精确的虚拟化，OVX必须保持网络状态视图的更新。这包括：

1.探测拓扑和流表变化
2.网络变化及时更新到物理网络和物理交换机上
3.检测，并在必要时，将变化应用到租户网络

OVX不仅完成拓扑发现，而且将虚拟拓扑呈现给租户。这些均通过操作LLDP实现。前两节内容描述了OVX如何通过网络拓扑和状态来保持物理网络同步。然后描述了OVX如何给租户控制器呈现虚拟网络，以使租户产生他们正在控制真实网络的错觉。

3.4.1 拓扑发现/LLDP处理

物理LLDP处理。从网络中接收到的LLDP消息或是发到网络中的LLDP消息由SwitchDiscoveryManager处理。先前提到，SwitchDiscoveryManager与PhysicalSwitch链路对保存在PhysicalNetwork.discoveryManager。在每个可能的毫秒级，每一个SwitchDiscoveryManager经由它配对的交换机发送出LLDP。默认1000毫秒，该参数定义在SwitchDiscoveryManager构造函数中。由于LLDP包会被邻近的交换机拦截同时上传到OVX上，SwitchChannelHandler通过调用PhysicalNetwork.HandleLLDP()来拦截他们。这个方法通过LLDPEventHandler [net.onrc.openvirtex.core.io]接口定义，由网络超类实现。HandleLLDP()调用已收到LLDP包的物理交换机配对的SwitchDiscoveryManager。SwitchDiscoveryManager的整体行为说明如下：

更新物理网络。SwitchDiscoveryManager.run()在毫秒级内更新拓扑结构。OVX定义了两种类型的端口：

·        fast：成功接收LLDP的端口（也就是说是链路的终端）

·        slow：发送MAX_PROBE_COUNT数量的LLDP包未被确认的端口（也就是说，端口是边缘端口，或者端口并不是链路的一部分。MAX_PROBE_COUNT当前值为3）

接收到LLDP报文的端口被认为是快速端口，在接收方的交换机的SwitchDiscoveryManager上设置快速端口，对于每个由快速端口发送的LLDP报文，其探测计数将会递增。相反地，报文被确认后，计数则会递减。探测计数存储在Map<Short,AtomicInteger> portProbeCount中。当端口的探测计数超过最大探测数MAX_PROBE_COUNT，将变成慢速端口。从慢速到快速端口的更新与探测计数的递减发生在SwitchDiscoveryManager.ackProbe()中，与之相反的情况在run()中实现。

3.4.2PhysicalSwitch统计集合

先前提到，与物理交换机有关的统计有两种结构：

·        AtomicReference<Map<Short, OVXPortStatisticsReply>>portStats；

·        AtomicReference<Map<Integer, List>> flowStats;

这些映射通过StatisticsManager[net.onrc.openvirtex.elements.datapath.statistics]的物理交换机实例来完成，这个交换机轮询了OFFlowStatisticsRequests和OFPortStatisticsRequests之间相应的datapath。

物理流表同步。在PhysicalSwitch中流表表示为PhysicalSwitch.flowStats结构，FlowStatisticsRequests通过定期轮询OFFlowStatisticsRequests相应的datapath来填充这个结构，这个过程是由每个StatisticsManager[net.onrc.openvirtex.elements]的PhysicalSwitch实例编排。当前轮询间隔30秒，由refreshInterval设置。除了流量统计，StatisticsManager还通过轮询OFPortStatisticsRequests的datapath来收集端口统计。

3.4.3 OVXNetwork呈现

虚拟拓扑呈现。OVX从运行自己的拓扑发现的租户控制器中接收到包含LLDP的PacketOut。来自租户的LLDP在OVXNetwork中处理。通过在虚拟域中处理LLDP，OVX显著减少了物理网络中的LLDP包的数量。

对于每个存在这种探测包的输出端口，OVXNetwork：

1.通过neighborPortMap查找目的端口
2.构造一个带有Inport的PacketIn到目的地
3.通过包含目的端口的OVXSwitch发送PacketIn到NOS

换言之，对于每一个租户拓扑，OVX模拟了网络中LLDP包广播、接收的过程。这个例程是由OVXNetwork.handleLLDP()实现。下图总结了这个过程。

3.5 网络虚拟化

在OVX中，虚拟化和去虚拟化是在虚拟层面与物理层面分界移动的逻辑动作，对于OpenFlow消息操作而言，这意味着一下几个步骤：

1.修改源和目的地网络地址；

2.从OVXSwitch/OVXPort和PhysicalSwitch/ PhysicalPort的主机附着点转换到/；

3.丢弃来自或发送到给定虚拟和物理网络拓扑中的无效点（主机、交换机）的消息。

1 源于物理和虚拟网络为主机（IP地址）和交换机（DPIDs和端口号）所使用的不同寻址方案。2逻辑上遵循1，由于主机的连接点也会根据网络视图有不同的命名。3用来隔离虚拟网络之间的流量。本节提供了这三个过程中发挥作用的各种机制的描述。

3.5.1 交换机表示转换

在消息处理期间，虚拟化过程中的一个关键功能就是OVXSwitch和PhysicalSwitch之间的转换。

OVXSwitch->PyhsicalSwitch(南向):

OVXSwitch拦截租户控制器发送的南向消息。查询目的PhysicalSwitch的方法有以下两种：

·        通过入口OVXPort：PhysicalSwitch通过映射到OVXPort的PhysicalPort发现，该OVXPort通过消息中的端口字段发现，如：OFMatch结构中的in_port域。对于一个OVXBigSwitch来说，任何没有入端口的值都将被忽略。

·        通过OVXMap查询：对于一个OVXSingleSwitch，1:1的映射允许OVX通过租户ID在physicalSwitchMap上直接查询。

在每个OVXSwitch子类中实现的OVXSwitch.sendsouth()方法中查找。

PhysicalSwitch -> OVXSwitch (北向):

反向查找过程开发了OVX如何定义租户网络和如何进行OpenFlow通信。

租户网络：主机不能被连接到一个以上的OVXNetwork，主机可通过MAC地址作为唯一的标识。通过使用从OFMatch字段中得到的MAC地址，租户ID可以从OVXMap的macMap中取得。

OpenFlow通信：OpenFlow针对同一次会话中的多条消息里的某些字段使用相同的值，OVX可使用新值来代替南向消息的cookie、XID、buffer id字段，或者当接收到相应的应答时（北向）可被映射成原本的状态。下一节将进一步讨论字段转换的过程。

3.5.2 OpenFlow字段转换—Cookie，BufferID，XID

OVX使用下列几种结构来保持字段翻译中使用的映射：

·        XidTranslator [net.onrc.openvirtex.datapath] :LRULinkedHashMap<Integer, XidPair> xidMap

·        OVXFlowTable [net.onrc.openvirtex.datapath] : ConcurrentHashMap<Long,OVXFlowMod> flowmodMap

·        OVXSwitch : LRULinkedHashMap<Integer, OVXPacketIn>bufferMap

XIDTranslator.XID值必须在每一个datapath内是唯一的。XIDTranslator使用OpenFlow的XID来复用/解复用一个数据通路和多租户之间的通信。对于每个南向OVXMessage，XIDTranslator：

1.生成一个新的XID；

2.创建一个XidPair来存储原来的XID和源OVXSwitch；

3.在xidMap中使用新的XID作为键来存储XidPair；

4.给调用者返回新的XID。

XidTranslator.translate()实现以上的动作。调用者（PhysicalSwitch）用新的值来代替消息中的XID，这样一个datapath就仅有一个唯一的XID用于接收消息。对于北向消息，XIDTranslator：

1.恢复给定消息的XID的XidPair；

2.返回XidPair给调用者。

发起会话的租户可以从XidPair中的OVXSwitch得以恢复,这个相反的过程由XidTranslator.untranslate()实现。

OVXFlowTable .OVXFlowTable以map形式存储新的流表项，该map以OVX生成的cookies作为key，对应的value是未被修改的OVXFlowMods，生成的Cookie用于编码源租户ID：

private longgenerateCookie() {

    ...

        final int cookie =this.cookieCounter.getAndIncrement();

        return (long) this.vswitch.getTenantId()&lt;&lt; 32 | cookie;

    }

}

cookieCounter确保了OVXSwitch内cookie的唯一性。具体地讲，当FlowMod增加流表时被OVXFlowMod.devirtualize()分配一个新的cookie，新cookie在流表中作为匹配机制,也就是说当OVX接收FlowRemoved时，必须删除条目，以保持与网络的状态的一致性。

bufferMap.PacketIn/PacketOut引用同一个bufferID。在消息的转换过程中，需要将来自packet_in的buffer_id和生成的buffer_id存起来，当packet_out数据下发时，需要查找并转换。

// use bufferID ofPacketOut to recover original (unmodified) PacketIn

final OVXPacketIncause = sw.getFromBufferMap(this.bufferId);

…

// recover originalOFMatch, packet data

this.match = newOFMatch().loadFromPacket(cause.getPacketData(),this.inPort);

this.setBufferId(cause.getBufferId());

ovxMatch = newOVXMatch(match);

ovxMatch.setPktData(cause.getPacketData());

如上所示，所存储的PacketIn内容被用来逆转之前虚拟化过程中地址、端口以及bufferID的转换。接下来讨论地址虚拟化的机制。

3.5.3 地址虚拟化

3.5.3.1综述

OVX为每个主机创建虚拟地址（OVXIPAddress）和物理地址（PhysicalIPAddress）以避免租户流量之间存在地址空间冲突。虚拟地址在租户的OVXNetwork中是唯一的，而物理地址在整个物理网络中是唯一的。虚拟和物理IP地址之间转换可保证每个租户控制器依照其网络的编址方案（尽管可能与其他租户方案重叠）来处理流，并且datapath有能力识别不同租户的流量。

地址转换将datapath分成两组：

·        边缘：含有主机挂载的datapath；

·        核心：datapath仅和其他datapath相连。

边缘datapath用于重写IP地址。边缘交换机主要用于以下两个方面：

1. 对于网络侧的流量，nw_src和nw_dst字段进行OVXIPAddress值匹配，将OVXIPAddress重写成PhysicalIPAddress；

2.对于来自主机侧的流量，匹配PhysicalIPAddress值，将PhysicalIPAddress重写成OVXIPAddress
核心交换机依据PhysicalIPAddresses进行匹配和转发。

OVX拦截并改变FlowMod以便将这些行为添加到datapath上。除了FlowMod， OVX也改变PacketIn和PacketOut——核心datapath只能“看见”PhysicalIPAddress值，控制器只能看见OVXIPAddres值。图3.6描述地址虚拟化的过程。表2表示一组由租户控制器发送到OVX，OVX到datapath的可能FlowMod，以达到虚拟化。

图3.6虚拟化过程

虚拟化过程流程如下：

a)PacketIn消息携带OVXIP值，未经修改发送到租户控制器；

b)相应的FlowMod匹配OVXIP，并将值重写为PhysicalIP；

c)虚拟链路通过psw2映射回两跳路径；

d)目的地边缘的PacketIn与核心网络中的转换行为一致；

e)OVX下发与PhysicalIP匹配的FlowMod消息，并将它们重写回OVXIP。

图3.6 三个datapath的地址虚拟化过程，交换机标识的数字表示端口号。在租户网络和实际网络中，端口号可能不同，即使是准确的映射，如pws1和vsw1。这里，h1开始发送数据包到h2，OVX根据目标datapath相对于源和目的主机中的位置分别处理PacketIns（租户方向箭头）和FlowMods（网络方向箭头）。

表2：到OVXSwitch和datapath可能的FlowMod消息集合

该行为的注意事项在ARP报文处理中介绍，具体见3.5.4节。

3.5.3.2实现

转换过程通过下列几个OVXMessage类实现：

PhysicalIPAddress -> OVXIPAddress:
* OVXPacketIn

OVXIPAddress -> PhysicalIPAddress:
* OVXPacketOut
* OVXFlowMod
* OVXActionNetworkLayerSource/Destination

图3.7、3.8、3.9按顺序展示了OVXPacketIn、OVXPacketOut、OVXFlowMod消息的虚拟化与去虚拟化过程。

图3.7：PacketIn虚拟化

图3.8：PacketOut去虚拟化

图3.9：FlowMod去虚拟化

3.6 状态同步

3.6.1 组件状态协调(原文未完善)

3.6.2 错误升级

OVX使用错误拦截来同步物理网络。网络中的错误，如端口、链路、交换机出现问题，将通过OFPortStatus消息发送到OVX上。目前OVX的实现期望PortStatus消息的OFPortReason字段携带具体原因值，如发生故障的交换机在该消息中携带原因值OFPPR_DELETE来发送。OVX将这些PortStatus消息作为OVXPortStatus[net.onrc.openvirtex.messages]实例处理。

OVXPortStatus消息的处理依赖于OVX的状态。在一个简单的案例中，只有端口、链路而没有租户网络的存在，PhysicalNetwork中的交换机将被除去。即使存在租户，在给定具有特定属性的虚拟拓扑结构的网络中，OVX也具有隐藏错误情况的能力。

·        OVXBigSwitches网络：non-OVXPort中的端口故障与网络故障是相似的。BVS中的端口如果发生故障则可以在租户网络中完全隐藏，前提是：BVS的OVXPorts之间存在替代路径，或者没有SwitchRoutes使用这些端口。

·        冗余OVXLink：如果在OVXPort定义的OVXLink之间有多条链路是可用的，端口在一条路径失效的情况下可以通过故障转移到另一条路径。

此外，未映射端口的故障将被简化到最简单的情况。图3.10显示了可以由OVX抑制的故障情形。

图3.10 OVX抑制故障

图3.10三种情况中的错误可以被抑制。左）PhysicalSwitches b和c未映射到OVXNetwork，租户对于b和c以及与它们相关的错误完全是无知的。中）多个物理路径映射到vs1和vs2之间的OVXLink([a-b,b-d],[a-d],[a-c,c-d]…)，提供足够的备份路径，这样就不会有链路故障报告给租户，除非a和d之间的所有路径均出现了故障，或者是PhysicalPorts映射到OVXPorts失败。右）整个PhysicalNetwork映射到一个BVS和crossbar。PhysicalLinks、端口和交换机的故障可能会被隐藏，除非a和d之间的SwitchRoute用完了路径，或OVXPorts失败。

OVXBigSwitch和OVXLink灵活性在3.7节中讨论。顺便说一句，当发生下列情况时错误升级仅影响视图：

（1）映射到OVXLinks和SwitchRoutes的OVXPorts；

（2）非弹性路径部分；

（3）映射到OVXSwitch边缘端口。

已删除的PhysicalPort的移除过程遵循3.2.3节的图3.3中所描述的依赖关系树，详情可查看3.2.3，完整的错误升级过程在OVXPortStatus.virtualize()中实现。

3.6.3 流表状态同步

OVXFlowTable 同步：

OVXFlowTable存储南向FlowMod消息，这些消息在devirtualization过程中会修改，OVXFlowTable代表租户控制器能查看到交换机（事实上是OVXSwitch）的流表。OVX通过处理OVXFlowMods[net.onrc.openvirtex.messages]来维护一个交换机流表的更新，就像datapath直接处理FlowMod消息一样：

/* Within classOVXFlowMod */

public voiddevirtualize(final OVXSwitch sw) {

    ...

    FlowTable ft = this.sw.getFlowTable();

    ...

    long cookie = ((OVXFlowTable)ft).getCookie();

    //Store the virtual flowMod and obtain thephysical cookie

    ovxMatch.setCookie(cookie);

    /* update sw's OVXFlowTable */

   boolean pflag = ft.handleFlowMods(this, cookie);

OVXFlowTable.handleFlowMods()根据FlowMod的command字段值修改OVXFlowTable实例中的条目。流条目匹配机制是由OVXFlowEntry[net.onrc.openvirtex.elements.datapath]实现，OVXFlowEntry是OVXFlowMod的一个封装类。虚拟流表更新后，devirtualization过程发送FlowMod消息。

物理流表同步：

物理流表表示为PhysicalSwitch.flowStats结构，定期轮询OFFlowStatisticsRequests相应的datapath由FlowStatisticsRequest填充。这个过程是由StatisticsManager[net.onrc.openvirtex.elements.datapath.statistics]的每个PhysicalSwitch实例编排。当前默认轮询间隔为30秒，通过refreshInterval设置。除了流量统计，StatisticsManager还通过轮询OFPortStatisticsRequests相关datapath来收集端口统计信息。

流表之间的同步：

物理流表通过去虚拟化FlowMod隐式地与映射到它上面的OVXFlowTable同步，每个发送到南向的FlowMod均有OFPFF_SEDN_FLOW_REM标志设置，这样在流表失效时会发送一个OFFFlowRemoved回复给OVX，OVXFlowRemoved[net.onrc.openvirtex.messages]的virtualize()方法决定并移除匹配使用cookie值的FlowMods：

/* Within classOVXFlowMod */

public void devirtualize(finalOVXSwitch sw) {

    ...

    FlowTable ft = this.sw.getFlowTable();

    ...

    long cookie = ((OVXFlowTable)ft).getCookie();

    //Store the virtual flowMod and obtain thephysical cookie

    ovxMatch.setCookie(cookie);

    /* update sw's OVXFlowTable */

   boolean pflag = ft.handleFlowMods(this, cookie);

3.7 弹性

网络元素注定会失效，OVX试图通过允许某些组件进行到PhysicalNetwork的冗余映射以减少基础设施故障对OVXNetworks的影响：

·        OVXLinks：多径；

·        SwitchRoute：多径；

·        OVXBigSwitch：多个SwitchRoutes，PhysicalSwitches集合，或SwitchRoutes具有多个路径。

 

注意：最后一种情况还没有得到落实，是假设。未来版本将支持BVS应变能力。

网络中端口和链路失效时，映射到多个路径的组件可以切换到备用路径，这使得持续的流量处理中断最小。支持故障转移映射的组件通过Resilient[net.onrc.openvirtex.elements]接口实现。这个接口提供两种方法：

·        public boolean tryRecovery(Component c)：考虑到C的失败，如果可能的话,尝试切换到任何备份的映射

·        public boolean tryRevert(Component c):考虑到C的恢复功能，试图切换回原来（有利于）的映射

目前，实现Resilient接口的两个组件是OVXLink和SwitchRoute。两者都使用类似的机制来实现Resilient接口。

图3.11和3.12分别说明用于tryRecovery()和tryRevert()流程图。

图3.11：故障切换过程

当PhysicalLink发生故障时，最高优先级路径（不包括该故障链路）替换当前路径，被替换的路径添加到故障列表中，这些新的链接将从可用的备份列表中删除。

图3.12：故障恢复过程

发生故障的PhysicalLink备份后将启动恢复过程，一个组件将尝试恢复使用其在最初的映射。在像OVXLink和SwitchRoute的虚拟链路中，这被认为是具有最高优先级的路径，这些路径是较早从'损坏'列表移至'备份'列表。

流量中断的减少是通过传递交换路径之间的流量来实现的，重新安装FlowMod以通过新路径引导流量。在OVXLink和SwitchRoute中均通过switchPath()方法实现。

3.8 持续性

本节介绍实现虚拟网络配置持续性的子系统。

3.8.1 综述

像先前所提到的，OVX支持配置网络拓扑结构的持续性。当提供它可连接到的存储后端（数据库）时，OVX网络拓扑保存到数据库，并在重启时根据所存储的数据重新生成网络拓扑。目前使用MongoDB作为后端数据库。

在重启OVX前与重启后，不仅网络拓扑，而且所有ID（包括租户ID、DPID、端口号、链接ID、路由ID和主机ID）均被保留。然而，在OVXBigSwitches设置为“SPF”算法时，其中的SwitchRoutes并不会被保留，也就是说，在重新启动时会自动再生。

 

注：目前，虚拟交换机和物理交换机的流表条目除了初始的流条目都不会被还原，我们现在正在开发“实时迁移和快照”来支持系统持续性，所有必要的流将被保留。

3.8.2 配置参数

命令行选项用来配置OVX与存储后端的交互方式。

但是以下两种情况，OVX启动时没有预先配置虚拟拓扑：

·        如果OVX无法连接到数据库，日志中将生成错误信息，但这些信息不会影响OVX的正常运行；

·        使用选项“-db-clear”，所有的持久化数据从存储中删除。

3.8.3 相关包和类

除了Persistable接口，[net.onrc.openvirtex.db]也与持久化有关。这个包包含了OVXNetworks类定义文档，OVX和MongoDB交互的封装类。本节的其余部分将对[net.onrc.openvirtex.db]中的成员类概述。

3.8.3.1DBManger类

DBManager实现存储后端的读/写操作，OVX在启动时它被实例化为一个单例。
Fields：

// Databasecollection names

public static finalString DB_CONFIG = "CONFIG";

public static finalString DB_USER = "USER";

public static finalString DB_VNET = "VNET";

 

// Database object

privateDBConnection dbConnection;

 

// Map ofcollection names and collection objects

privateMap<String, DBCollection> collections;

 

// Mapping betweenphysical dpids and a list of vnet managers

privateMap<Long, List<OVXNetworkManager>> dpidToMngr;

// Mapping betweenphysical links and a list of vnet managers

privateMap<DPIDandPortPair, List<OVXNetworkManager>> linkToMngr;

// Mapping betweenphysical ports and a list of vnet managers

private Map<DPIDandPort,List<OVXNetworkManager>> portToMngr;

Methods：

// Initializedatabase connection

public voidinit(String host, Integer port, boolean clear)

 

// Create adocument in database from persistable object obj

public voidcreateDoc(Persistable obj)

// Remove adocument

public voidremoveDoc(Persistable obj)

 

// Save an elementto the list of specified key in document

public voidsave(Persistable obj

// Remove anelement from the list of specified key in document

public voidremove(Persistable obj)

 

// Reads allvirtual networks from database and spawn an OVXNetworkManager

// for each.

private voidreadOVXNetworks()

 

// Reads virtualcomponents from a list of maps in db format and registers the

// physicalcomponents in their manager.

private voidreadOVXSwitches(List<Map<String, Object>> switches,

                        OVXNetworkManager mngr)

private voidreadOVXLinks(List<Map<String, Object>> links,

                        OVXNetworkManager mngr)

private voidreadOVXPorts(List<Map<String, Object>> ports,

                        OVXNetworkManager mngr)

private voidreadOVXRoutes(List<Map<String, Object>> routes,

                        OVXNetworkManager mngr)

3.8.3.2OVXNetworkManager类

OVXNetworkManager根据存储后台重新生成租户网络，并创建每个虚拟网络。
Fields：

// Document ofvirtual network

privateMap<String, Object> vnet;

 

private IntegertenantId;

 

// Set of offlineand online physical switches

private SetofflineSwitches;

private SetonlineSwitches;

 

// Set of offlineand online physical links identified as (dpid, port number)-pair

private SetofflineLinks;

private SetonlineLinks;

 

// Set of offlineand online physical ports

private SetofflinePorts;

private SetonlinePorts;

 

private boolean bootState;

Methods：

// Document ofvirtual network

private Map<String,Object> vnet;

 

private IntegertenantId;

 

// Set of offlineand online physical switches

private SetofflineSwitches;

private SetonlineSwitches;

 

// Set of offlineand online physical links identified as (dpid, port number)-pair

private SetofflineLinks;

private SetonlineLinks;

 

// Set of offlineand online physical ports

private SetofflinePorts;

private SetonlinePorts;

 

private boolean bootState;

3.8.3.3interface DBConnection

DBConnection接口定义了OVX与各种存储后端的交互方法，这些方法必须按顺序执行。MongoConnection类实现此接口并与特定的MongoDB方法交互实现与数据库连接和断开。

3.8.4 存储配置

3.8.4.1概述

虚拟组件被实例化时，其信息作为文件被添加到数据库中。目前，存储在数据库中的组件如下：

·        OVXNetwork

·        OVXSingleSwitch

·        OVXBigSwitch

·        OVXPort

·        OVXLink

·        SwitchRoute

·        Host

本节的剩余部分介绍涉及存储的机制和结构。

3.8.4.2机制

当持久化的组件实例化时，register()方法被调用。在register()中，DBManger.save()通过传入可持续化对象被调用，save()方法将包括如下操作：

1.通过getDBName()得到目标集合，例如：“VNET”；

2.通过getDBIndex()获取查询索引，例如：{ “tenantId”:1 }；

3.通过getDBKey()获取键，通过getDBObject()获取值。如：Key是“swtich”，值为{“dpids”:[4],”vdpid”:400}；

4.添加（更新）这个值到这个Key的列表，使用MongoDB的$addToSet操作。如果初始集合为{“switch”：[{“dpids”：[1]，“vdpid”：100}]}，执行操作后成为{“switch”：[{“dpids”：[1]，“vdpid”：100}，{“dpids”：[4]，“vdpid”：400}]}

注意，$addToSet不允许列表中的复制，请参阅MongoDB的文档作进一步的研究。

3.8.4.3可持续化组件

实现可持续化并存储到数据库中的组件是OVXSwitch子类（OVXSingleSwitch，OVXBigSwitch）、OVXLink、SwitchRoute、OVXPort和Host。注意，OVXNetwork、Link和Port也实现了可持续化但是并未存储到数据库中，即未调用DBManager.save()，PhysicalLink (extends Link)、PhysicalPort(extends Port)和OVXNetwork都可以调用Persistable中的方法。

3.8.5 更新配置

当组件（交换机、链路、端口、主机）更新时，OVX删除旧的实例，并用新的实例替换它。数据库中的元素也将在相应的时间进行删除和创建。该过程中OVXNetworks和其他组件之间是不同的：

OVXNetworks：DBManager.removeDoc()删除指定虚拟网络的文件，OVXNetwork.unregister()调用这个方法。
其他元素：DBManager.remove()通过MongoDB中的$pull操作为特定的Key删除列表中的元素。

这个方法被叫做组件钝化法来调用：

·        unregisterDP() – OVXSwitch

·        unregister() – OVXPort, OVXLink, SwitchRoute, OVXHost

3.8.6 恢复配置

OVX一旦启动，就会添加先前在数据库中“离线列表”中存储的物理组件。“离线列表”是一个清单，用来追踪物理实体（交换机、链接、端口）是否离线。当OVX检测到一个物理元件活跃时，OVX创建其对应的物理组件实例（PhysicalSwitch、PhysicalPort、PhysicalLink），如果所有的物理实体变成活跃时，OVX恢复保存的OVXNetwork，包括它们的虚拟组件（如OVXSwitch、 OVXPort、 OVXLink和Host）。