CN108780408B - 基于全局实现号识别逻辑实体的实现状况 - Google Patents

Abstract

一些实施例提供了用于确定逻辑网络的一个或多个逻辑实体的实现状况的方法。该方法在每次发生特定事件时就递增实现号的值并将递增后的值发布到逻辑网络的一组控制器。在接收到指定逻辑网络的逻辑实体的状态的数据后，该方法将逻辑实体状态的数据发布到该组控制器。在一些实施例中，该方法向该组控制器查询直到特定时间点为止发布到该组控制器的一组逻辑实体的状态数据的实现状况。在一些实施例中，所提交的查询包括与特定时间点相关联的实现号的特定值。

Description

基于全局实现号识别逻辑实体的实现状况

背景技术

在分布式虚拟网络(例如，逻辑网络)中，网络功能和服务由逻辑网络元件(例如，诸如逻辑交换机和逻辑路由器的一组逻辑转发元件)实现。从用户(例如，网络管理员)接收每个逻辑网络元件(逻辑实体)的定义，并且定义逻辑实体的数据存储在逻辑网络的管理平面。然后，管理平面将这些数据推送到逻辑网络的控制平面，以实现逻辑实体(例如，配置和实现逻辑实体)。目前，很难或不可能确定在特定时间点是否已在网络基础设施中(例如，在控制器、管理程序等中)实现了一组逻辑实体。此外，当在特定时刻逻辑实体没有被正确实现时，没有特定的方法来识别问题的来源。

发明内容

一些实施例提供用于确定在特定时间点在网络中是否实现逻辑网络的一组逻辑实体(例如，逻辑转发元件、逻辑中间盒等)的期望状态的方法和工具。在一些实施例中，该方法查询逻辑网络的控制平面以识别在特定时刻的逻辑实体的实现状况。一些实施例的方法还能够识别其上未实现逻辑实体的期望状态的物理节点(例如，控制器和受管理转发元件)。在一些实施例中，逻辑网络的逻辑实体的期望状态包括逻辑网络的管理平面(MP)基于(例如，从用户接收到的)逻辑网络的定义生成的并且存储在MP配置数据库中的数据。在一些实施例中，所生成的数据(期望状态)被异步地(例如，通过MP信道)推送到中央控制平面(CCP)集群(例如，CCP集群的一个或多个中央控制器)。

CCP集群处理接收到的数据以及CCP集群从实现逻辑实体的一个或多个受管理转发元件(MFE)接收的逻辑实体的对应运行时数据。当CCP集群将处理后的配置数据(例如，通过其中每个都控制对应的MFE的一组本地控制器)向下推送到MFE以便配置MFE(每个MFE在主机机器的管理程序上操作)上的逻辑实体时，一些实施例确定逻辑实体在系统中(即，在其上实现一个或多个逻辑网络的物理网络基础设施中)被实现。一些实施例确定当逻辑实体实际上在MFE上被配置时逻辑实体在系统中被实现。

与逻辑实体的期望状态不同，逻辑实体的已实现状态涉及短暂的系统状态。即，随着系统试图收敛到期望状态，逻辑实体的已实现状态不断地改变。换句话说，随着系统(例如，数据中心)的环境改变(例如，虚拟机迁移、管理程序故障等)，已实现状态可能在任何时间点变成未实现。在一些实施例中，还可以通过在逻辑网络的控制平面处接收到的运行时数据(例如，虚拟网络接口的L2和L3地址)来改变(更新)逻辑实体的已实现状态。

一些实施例不是在创建逻辑实体之后查询逻辑实体(例如，逻辑交换机、逻辑交换机端口、逻辑路由器等)的状态以确保逻辑实体被实现，而是它们提供实现确定工具，该实现确定工具允许用户在不同的时刻一起查询一个或多个逻辑实体的实现状况。即，当多个逻辑实体被添加到逻辑网络时，不是查询每个逻辑实体的状态以确保实体在系统中被实现，而是用户可以查询控制平面(例如，通过管理平面)来确定直到特定时间点为止被发布到CCP集群的每个逻辑实体(或特定一组逻辑实体)的实现状况。

为了这样做，一些实施例提供集群范围单调增加值，其实际上是跟踪CCP集群处的逻辑实体的期望状态的实现的状态同步屏障(barrier)。在一些实施例中，该全局实现号(GRN)在不同的时刻递增(例如，以某些时间间隔自动地递增、在每个用户请求下手动地递增、或者在每个期望状态更新时递增)。管理平面除了向CCP集群发布期望状态之外，还在每次GRN递增时，向CCP集群发布新的GRN值。然后，CCP集群将接收到的GRN值与直到接收到GRN值时为止发布到CCP集群的不同逻辑实体的实现状态相关联。在一些实施例中，CCP集群还将GRN与控制平面从MFE接收到的逻辑实体的对应运行时状态相关联。

然后，一些实施例的管理平面可以请求直到最新GRN或(例如，由用户给出的)任何特定GRN为止发布到CCP集群的(例如，由用户指定的)特定一组逻辑实体的实现状况。一些实施例还提供直到最新GRN或任何特定GRN为止发布到CCP集群的每个逻辑实体的已实现状态。例如，当用户沿着逻辑路由定义具有多个逻辑元件(例如，逻辑交换机和路由器)的逻辑路由时，逻辑路由的实现状况取决于沿着路由的每个单个逻辑元件的实现。由此，为了识别逻辑路由的实现的状况，用户可以在定义路由之后发布的GRN值中查询路由的已实现状态。

为了这样做，用户(例如，网络管理员)可以在逻辑路由被定义之后请求GRN递增(例如，通过调用GRN递增函数)。这样的请求不仅递增GRN并且在做出请求时将递增的GRN值与逻辑实体的实现状况相关联，而且还将递增的GRN值返回给用户。然后，用户可以向CCP集群查询直到接收到的GRN值为止的逻辑路由的实现状况。

对于CCP节点(例如，控制器)最后处理的每个GRN，CCP节点知道CCP节点管理的每个MFE(例如，CCP节点对于其是主节点(master)的MFE)上的逻辑实体的实现状况。因此，当用户请求特定GRN处的期望逻辑对象的实现状况(即，用户向MP查询特定GRN处的已实现状态)时，一些实施例的CCP集群通过返回直到特定GRN为止的所有逻辑实体的状况作为响应。在响应中，CCP集群包括尚未实现逻辑实体的任何MFE(例如，执行MFE的管理程序)。例如，对于散布到管理程序子集的分布式防火墙(DFW)规则部分(即，规则部分所依赖的逻辑交换机和路由器跨越管理程序的子集)，CCP节点在对查询的回复中包括实现逻辑转发元件的管理程序的子集的状况。在一些实施例中，CCP节点仅在回复中包括其上未实现逻辑实体的管理程序。

一些实施例的CCP集群(例如，CCP集群中的一个或多个CCP节点)返回用于逻辑实体的实现状况的消息(响应于逻辑实体的实现状态查询)。在一些实施例中，返回的消息可以是成功消息、非成功消息或进行中消息。在一些实施例中，成功状况指示CCP集群已处理接收到的期望状态并将处理后的数据推送到本地控制平面(例如，在同一主机机器中与MFE一起操作的一个或多个本地控制器)。在一些实施例中，每当MP递增GRN时，MP将递增的GRN与CCP集群同步。在一些实施例中，控制器节点之一(例如，分片(sharding)主控制器)将相同的GRN分配给保持在CCP集群的控制器处的当前运行时状态。在一些实施例中，当CCP集群已针对特定GRN值处理逻辑实体的期望状态和对应运行时状态时，认为针对GRN的特定值的实现状况是成功的。

在一些实施例中，成功消息不仅指示逻辑实体的期望状态(以及对应的运行时状态)已经由CCP集群处理和发布，而且还指示逻辑实体已成功配置在实现逻辑实体的(在主机机器或网关上操作的)一个或多个MFE上。例如，在一些这样的实施例中，对逻辑交换机的已实现状态的成功响应意味着(例如，在一个或多个主机机器的管理程序上)实现逻辑交换机的一个或多个MFE成功地连接到一个或多个虚拟机器，该一个或多个虚拟机器逻辑上连接到逻辑交换机。它还意味着MFE与逻辑交换机的控制平面(例如，逻辑交换机的主控制器)和管理平面(例如，逻辑交换机的主管理器)有活动通信。

在一些实施例中，对于逻辑实体的状况的不成功实现响应可能具有不同的原因。例如，当一个或多个CCP节点在处理期望状态更新中落后时，CCP节点可能返回期望状态的不成功实现。对于逻辑实体的期望状态的不成功实现的其它原因包括，当一个或多个MFE明确指示它们未能针对GRN的特定值实现一些变化时、当一个或多个MFE在跟上期望状态更新频率中落后时、当一些MFE长时间断开连接时，等等。

一些实施例提供世代号(例如，在GRN内)以识别群集事件、时间片重新分配(slicereassignment)、或者何时MP数据库被安装和/或恢复。在一些实施例中，每次发生群集事件或时间片重新分配时或者每次恢复管理平面数据库时，递增世代号。在一些实施例中，这种递增自动发生(例如，对于每个新的群集事件)。在一些实施例中，用户还可以(手动)递增世代号(例如，当恢复MP数据库的备份版本时)。

在一些实施例中，MP查询(例如，通过远程过程调用)CCP集群以确保世代号在所有CCP节点之间同步。在一些这样的实施例中，每个CCP节点用其最新的世代号回复查询。当所有回复中的世代号不相同时，MP可以断定，最近发生的某些群集变化尚未被CCP节点中的一些处理。在一些实施例中，通用唯一标识符(UUID)包括世代号和GRN两者(例如，GRN和世代号两者都可以被编码在单个64位UUID中，其中UUID的较高16位保持世代号并且较低的48位保持GRN)。

一些实施例提供故障诊断数据以帮助识别期望状态的实现中的各种问题的来源。一些实施例基于识别出的问题的性质和位置为有问题的逻辑实体提供不同级别的细节。一些实施例提供关于未能被实现的特定逻辑元件的故障诊断数据。

前述发明内容旨在用作对本发明的一些实施例的简要介绍。它并不意味着是对本文件中公开的所有发明主题的介绍或概述。下面的具体实施方式和具体实施方式中提及的附图将进一步描述发明内容中描述的实施例以及其它实施例。因此，为了理解本文件描述的所有实施例，需要对发明内容、具体实施方式和附图进行全面回顾。此外，所要求保护的主题不受发明内容、具体实施方式和附图中的说明性细节的限制，而是由所附权利要求限定，因为在不脱离本主题的精神的情况下，所要求保护的主题可以以其它特定形式体现。

附图说明

在所附权利要求中阐述了本发明的新颖特征。但是，出于解释的目的，在以下图中阐述了本发明的若干实施例。

图1图示了用于逻辑网络的一组逻辑实体的创建和发布。

图2图示了用户使用全局实现号(GRN)跟踪逻辑网络的逻辑实体的实现状况。

图3图示了创建分布式防火墙规则并向控制平面(例如，通过管理平面)查询防火墙规则的实现状况的示例。

图4图示了在一些实施例中更新(递增)GRN的一种方法，其以某些时间间隔自动更新GRN值。

图5概念性地图示了中央管理平面集群、中央控制平面集群和诸如数据中心的托管系统中的一组主机机器之间的关系。

图6概念性地图示了一些实施例的过程，其向CCP集群查询特定GRN并基于该过程从CCP集群接收到的响应来报告逻辑实体的实现状况。

图7图示了在接收到针对特定GRN处的一个或多个逻辑实体的实现状况的查询之后一些实施例的控制平面返回的响应的示例。

图8图示了在接收到针对特定GRN处的一个或多个逻辑实体的实现状况的查询之后一些实施例的控制平面返回的响应的另一个示例。

图9概念性地图示了用于实现本发明的一些实施例的电子系统。

具体实施方式

在本发明的以下详细描述中，阐述和描述了本发明的许多细节、示例和实施例。但是，应该理解的是，本发明不限于所阐述的实施例，并且可以在没有所讨论的一些具体细节和示例的情况下实践本发明。

一些实施例提供用于确定在特定时间点在网络中是否实现逻辑网络的一组逻辑实体(例如，逻辑转发元件、逻辑中间盒等)的期望状态的方法和工具。在一些实施例中，该方法查询逻辑网络的控制平面以识别在特定时刻的逻辑实体的实现状况。一些实施例的方法还能够识别其上未实现逻辑实体的期望状态的物理节点(例如，控制器和受管理转发元件)。在一些实施例中，逻辑网络的逻辑实体的期望状态包括逻辑网络的管理平面(MP)基于(例如，从用户接收到的)逻辑网络的定义生成的并且存储在MP配置数据库中的数据。在一些实施例中，所生成的数据(期望状态)被异步地(例如，通过MP信道)推送到中央控制平面(CCP)集群(例如，CCP集群的一个或多个中央控制器)。

CCP集群处理接收到的数据以及CCP集群从实现逻辑实体的一个或多个受管理转发元件(MFE)接收的逻辑实体的对应运行时数据。当CCP集群将处理后的配置数据(例如，通过其中每个都控制对应的MFE的一组本地控制器)向下推送到MFE以便配置MFE上的逻辑实体时，一些实施例确定逻辑实体在系统中(即，在其上实现一个或多个逻辑网络的物理网络基础设施中)被实现。一些实施例确定当逻辑实体实际上在MFE(在一些实施例中也称为传输节点)上被配置时逻辑实体在系统中被实现。

与逻辑实体的期望状态不同，逻辑实体的已实现状态涉及短暂的系统状态。即，随着系统试图收敛到期望状态，逻辑实体的已实现状态不断地改变。换句话说，随着系统(例如，数据中心)的环境改变(例如，虚拟机迁移、管理程序故障等)，已实现状态可能在任何时间点变成未实现。在一些实施例中，还可以通过在逻辑网络的控制平面处接收到的运行时数据(例如，虚拟网络接口的L2和L3地址)来改变(更新)逻辑实体的已实现状态。

一些实施例不是在创建逻辑实体之后查询逻辑实体(例如，逻辑交换机、逻辑交换机端口、逻辑路由器等)的状态以确保逻辑实体被实现，而是它们提供实现确定工具，该实现确定工具允许用户在不同的时刻一起查询一个或多个逻辑实体的实现状况。即，当多个逻辑实体被添加到逻辑网络时，不是查询每个逻辑实体的状态以确保实体在系统中被实现，而是用户可以查询控制平面(例如，通过管理平面)来确定直到特定时间点为止被发布到CCP集群的每个逻辑实体(或特定一组逻辑实体)的实现状况。

在一些实施例中，逻辑网络包括放置在网络的不同逻辑路径上的一组逻辑实体。逻辑网络中的逻辑实体的示例包括逻辑转发元件(LFE)，诸如逻辑L2交换机和逻辑L3路由器，逻辑中间盒，诸如逻辑防火墙和逻辑负载平衡器等。在一些实施例中，逻辑网络实体还包括其它网络元件，包括源或目的地数据计算节点(DCN)和(例如，由MFE实现的)隧道端点。虽然DCN或隧道端点通常在单个主机机器(或网关)上操作，但逻辑转发元件或逻辑中间盒跨越在不同机器上操作的若干不同MFE(例如，软件和/或硬件受管理转发元件)。

逻辑网络的逻辑转发元件在逻辑上将在不同主机机器上运行的若干不同DCN(例如，虚拟机(VM)、容器、物理机等)连接到彼此以及连接到其它逻辑和/或物理网络。在一些实施例中，逻辑上连接DCN的逻辑转发元件为托管系统(例如，数据中心)的用户(例如，租户)定义逻辑网络拓扑。在一些实施例中，DCN的不同子集驻留在执行软件受管理转发元件(MFE)的不同主机机器上。每个MFE在主机机器上操作并且实现在主机机器上运行的DCN子集逻辑上连接到的逻辑网络的LFE。

在一些实施例中，软件MFE是在主机机器的虚拟化软件(例如，管理程序)中实例化的软件实例。在一些实施例中，在主机机器上实现LFE包括对源自和/或去往驻留在MFE在其上操作的主机机器上的一组DCN的报文执行网络流量转发处理。LFE也由一个或多个硬件MFE(例如，架顶式(TOR)交换机)实现，以便将连接到硬件MFE的物理机器(例如，服务器、主机机器等)逻辑上连接到逻辑网络的其它DCN。此外，由于特定物理主机机器可以托管多于一个逻辑网络的DCN(例如，属于不同租户)，因此在主机机器(或硬件MFE)上运行的软件MFE可以被虚拟化以便实现属于不同逻辑网络的不同组LFE。

在一些实施例中，中央管理平面(CMP)集群(例如，CMP集群中的主管理器)生成逻辑网络拓扑的逻辑对象数据。在一些实施例中，用户(例如，网络管理员)通过应用编程接口(API)调用向CMP集群提供逻辑网络定义(例如，逻辑网络拓扑)。CMP集群基于接收到的逻辑网络定义生成逻辑实体数据(例如，通过定义逻辑交换机、逻辑路由器、逻辑中间盒等)并将生成的数据(即，逻辑实体的期望状态)存储在管理平面数据库中。

一些实施例的CMP集群还将期望状态推送到中央控制平面(CCP)集群中的一个或多个控制器。MFE(例如，在主机机器和网关机器中操作的MFE)还将与MFE实现的逻辑实体相关的运行时数据(即，逻辑实体的发现状态)推送到CCP集群。在一些实施例中，典型的运行时数据包括第2层控制平面表，诸如虚拟隧道端点(VTEP)表、媒体访问控制(MAC)表、地址解析协议(ARP)表；第3层路由表，诸如路由信息库(RIB)表、转发信息库(FIB)表；从MFE收集到的统计数据；等等。

CCP集群处理从管理平面接收到的逻辑实体定义数据(即，期望状态)以及从MFE接收到的运行时数据(即，发现状态)，以便在MFE上配置逻辑实体(即，实现系统中的逻辑实体)。换句话说，逻辑网络的一个或多个逻辑实体的处理后的配置数据和存储在CCP集群中的对应运行时数据构成逻辑实体的已实现状态。然后，CCP集群将逻辑实体的已实现状态向下推送到主机机器(和网关)。一些实施例确定当CCP集群(例如，CCP集群中的控制器)将处理后的配置数据向下推送到MFE时逻辑实体的期望状态被实现。一些实施例确定当不仅配置数据被控制器处理和分发，而且逻辑实体实际上在实现逻辑实体的MFE上被配置时逻辑实体的状态被实现。

分发到主机机器的配置数据定义在主机机器上操作的MFE的公共转发行为，以便实现逻辑实体。在一些实施例中，在每个主机机器上(例如，在主机机器的管理程序中)操作的本地控制器首先从CCP集群接收配置数据。然后，本地控制器生成定制的配置数据，该定制的配置数据定义在本地控制器在其上操作的同一主机机器上操作的每个MFE的特定转发行为。CCP集群与实现逻辑实体的其它MFE共享在每个MFE上实现的逻辑实体的已实现状态，以便促进不同MFE之间的逻辑网络流量的通信。

总而言之，逻辑网络的MFE(即，受管理转发元件)是逻辑实体的运行时状态或发现状态的来源，而MP是逻辑实体的期望状态的来源。CCP集群处理(组合)这两个状态以实现逻辑实体。本地控制器从CCP集群接收已实现状态，以便在其对应的MFE上配置逻辑网络的逻辑实体。

当前，用户难以或有时不可能确定在网络基础设施中(例如，在CCP集群和MFE中)是否已经实现(用户已经创建的)一组逻辑实体的期望状态。图1图示了用于逻辑网络的一组逻辑实体的创建和发布。更具体而言，该图示出了用户如何(例如，通过API调用)请求管理平面创建一个或多个逻辑实体并将这些逻辑实体发布到控制平面。图1包括管理器110(例如，中央管理平面集群中的管理器计算机或应用)、期望状态事务队列120、控制器130(例如，CCP集群中的控制器计算机或应用)、以及显示期望状态事务是否在控制平面中被处理(实现)的已实现状态队列140。

该图示出管理器110已经(例如，通过用户API请求)生成逻辑交换机LS1、逻辑交换机LS1的逻辑端口LP1、逻辑交换机LS2和逻辑交换机LS2的逻辑端口LP2。但是，在管理器创建LP2之前，在期望状态事务队列120处接收到改变逻辑端口LP1的修改请求150。该修改请求可以从用户接收或者可以通过逻辑网络或实现逻辑网络的物理基础设施中的(例如，运行时数据中的)变化来接收。

该图还示出了当管理器110(例如，通过CCP处理程序模块)向CCP集群发布期望状态时，除了逻辑端口LP1的修改之外，所有创建的逻辑实体都在控制器130处被实现。换句话说，逻辑端口LP1被创建并且在一个时间点处在控制平面中被实现，但是，LP1的修改在控制平面中尚未被实现。除非CCP集群采用机制来维持逻辑实体在不同阶段的状态，否则几乎不可能确定逻辑实体在这些不同阶段的实现状况。

为了维持逻辑实体的状态，一些实施例提供集群范围单调增加值，其实际上是跟踪CCP集群处的逻辑实体的期望状态的实现的状态同步屏障。在一些实施例中，该全局实现号(GRN)在不同的时刻递增(例如，以某些时间间隔自动地递增、在每个用户请求下手动地递增、或者在每个期望状态更新时递增)。管理平面除了向CCP集群发布期望状态之外，还在每次GRN递增时，向CCP集群发布新的GRN值。然后，CCP集群将接收到的GRN值与直到接收到GRN值时为止发布到CCP集群的不同逻辑实体的实现状态相关联。在一些实施例中，CCP集群还将GRN与控制平面从MFE接收到的逻辑实体的对应运行时状态相关联。

然后，一些实施例的管理平面可以请求直到最新GRN或(例如，由用户给出的)任何特定GRN为止发布到CCP集群的(例如，由用户指定的)特定一组逻辑实体的实现状况。一些实施例还提供直到最新GRN或任何特定GRN为止发布到CCP集群的每个逻辑实体的实现状态。例如，当用户定义具有沿着逻辑路由的多个逻辑元件(例如，逻辑交换机和路由器)的逻辑路由时，逻辑路由的实现状况取决于沿着路由的每个单个逻辑元件的实现。由此，为了识别逻辑路由的实现状况，用户可以查询在定义路由之后发布的GRN值处的路由的实现状态。

为了这样做，用户(例如，网络管理员)可以在逻辑路由被定义之后请求GRN递增(例如，通过调用GRN递增函数)。这样的请求不仅递增GRN并且在做出请求时将递增的GRN值与逻辑实体的实现状况相关联，而且还将递增的GRN值返回给用户。然后，用户可以向CCP集群查询直到接收到的GRN值为止的逻辑路由的实现状况。

图2图示了用户使用全局实现号(GRN)跟踪逻辑网络的逻辑实体的实现状况。具体而言，该图示出用户使用不同的GRN值跟踪用户已经为逻辑网络的逻辑交换机创建的逻辑端口的实现。类似于图1的管理器110，管理器110包括期望状态事务队列120，其保持逻辑交换机LS1、逻辑交换机LS1的逻辑端口LP1、逻辑交换机LS2和逻辑交换机LS2的逻辑端口LP2。在接收逻辑端口LP2之前，期望状态事务队列120还接收到对逻辑端口LP1的修改150。

但是，与图1不同，该图示出管理器110还包括GRN生成器模块210，GRN生成器模块210递增GRN的值并在期望状态事务队列120中的每个期望状态更新之后将递增的值发布到控制器130。如下面将参考图4进一步讨论的，在每个期望状态更新之后递增GRN值并且发布递增的GRN仅是将GRN发布到一些实施例的管理平面执行的控制平面的一种方式。

在一些实施例中，管理平面在接收到用户请求后递增GRN值，而在一些其它实施例中，GRN值以(例如，可由用户调整的)某些时间间隔自动地递增。而在一些其它实施例中，可以使用前述三种方法中的两种或全部来递增GRN值并将其发布到控制平面。即，当GRN值以预设时间间隔递增和发布时，如果发生对期望状态的更新，则管理平面递增GRN值并将其发布到控制平面。此外，用户可以手动地强制递增和发布GRN值。

在图2中，在每个期望状态更新之后，GRN生成器210递增GRN的值并将新值发布到控制器130。如图所示，在将逻辑交换机LS1发布到已实现状态队列140之后，GRN生成器210已将GR的值G递增到G1并将该新值发布到控制器130。类似地，在分别发布逻辑端口LP1、逻辑交换机LS2和对逻辑端口LP1的修改之后生成新值G2、G3和G4并将其发布到控制器130。该图还示出了在系统中尚未实现对逻辑端口LP1的修改(如已实现状态队列140中LP1上的叉号指示)。

最后，该图示出用户30已经向管理平面发出对在GRN值G4处的逻辑端口LP1的实现状况的查询。响应于该查询，管理平面向控制平面查询相同内容，并向用户返回“未实现”响应。由此，用户识别出对逻辑端口LP1的修改已经失败并且未在系统中实现。然后，用户再次针对GRN值G3处的LP1的实现状况(其示出在端口修改之前在某个时间点该端口的实现状况)向管理平面进行查询。这次，管理平面响应于查询(在查询控制平面之后)返回“已实现”，其指示在GRN G3处已实现。从上述两个查询中，用户可以断定，逻辑端口LP1在其创建之后在系统中被实现，但在逻辑端口被修改之后未能被实现。如图所示，用户可以通过使用不同的GRN值跟踪在不同时间点的逻辑端口LP1。

如上所述，对于CCP节点(例如，控制器)最后处理的每个GRN，CCP节点知道CCP节点管理的每个MFE(例如，CCP节点对于其是主节点的MFE)上的逻辑实体的实现状况。即，当CCP节点接收到逻辑实体的期望状态和运行时状态时，CCP节点负责仅在网络的特定一组MFE上配置逻辑实体。在一些实施例中，由网络管理员分配该特定一组MFE(即，MFE在其上运行的管理程序)。替代地或者结合地，在一些实施例中，CCP节点管理的一组管理程序由管理器计算机或分片控制器自动地并且基于CCP节点的工作负载进行分配。

因此，当用户请求在特定GRN处的期望逻辑对象的实现状况时(即，用户向MP查询直到特定GRN为止的已实现状态)，一些实施例的CCP集群通过返回直到特定GRN为止的所有逻辑实体的状况作为响应。在响应中，CCP集群包括尚未实现逻辑实体的任何MFE(例如，执行MFE的管理程序)。例如，对于散布到管理程序子集的分布式防火墙(DFW)规则(即，防火墙规则所依赖的逻辑交换机和路由器跨越管理程序的子集)，CCP节点在对查询的回复中包括实现逻辑转发元件的管理程序的子集的状况。在一些实施例中，CCP节点仅在回复中包括其上未实现逻辑实体的管理程序。

图3图示了创建分布式防火墙规则并(例如，通过管理平面)向控制平面查询防火墙规则的实现状况的示例。该图示出用户310(例如，通过API调用)创建两个逻辑交换机，并且此后创建依赖于逻辑交换机的逻辑防火墙320。更具体而言，用户已经创建了第一逻辑交换机LS1、第一逻辑交换机的第一逻辑端口LP1、第二逻辑交换机LS2、第二逻辑交换机的第二逻辑端口LP2、以及逻辑防火墙FW。然后，用户已向防火墙FW添加了防火墙规则320，其指定应该阻止从逻辑交换机LS1到逻辑交换机LS2的任何网络流量。如图所示，防火墙规则320指定在系统中应该阻止具有逻辑交换机LS1的源地址(例如，IP地址)和LS2的目的地地址的任何报文。

用户希望能够确定此时(即，在添加防火墙规则之后)系统中是否实现逻辑防火墙。如所示示例所示，单个分布式防火墙(DFW)规则的实现可以取决于其端口上的许多逻辑交换机以及未示出的其它网络元件(例如，取决于到逻辑路由器的连接、取决于逻辑路由器端口上配置的IP前缀、取决于防欺骗配置、取决于容器配置等)。由此，为了识别DFW规则的实现的状况，用户可以在创建DFW规则之后查询GRN，以便确定规则所依赖的所有逻辑实体的实现状况。

在这个示例中，管理平面在每个期望状态更新之后递增GRN值。因此，在每个期望状态发布之后，GRN的新递增值也被发布到控制平面。即，递增值G1、G2、G3和G4分别与逻辑实体LS1、LP1、LS2和LP2相关联。但是，如逻辑端口330上的叉号指示，除了逻辑端口LP2之外，防火墙规则所依赖的所有逻辑实体都在系统中被实现。由此，当用户310向系统查询在GRN G4处防火墙FW的实现状况时，在一些实施例中，管理平面通过指示逻辑端口LP2是唯一未实现的逻辑实体来响应。

一些其它实施例在它们提供实现状况报告时不提供这种级别的粒度。相反，一些这样的实施例提供关于其上没有正确实现一个或多个逻辑实体的物理节点(例如，主机机器、网关机器等)的信息。在所示示例中，当查询DFW规则的实现状况时，一些实施例提供识别实现未实现逻辑端口LP2的一个或多个物理节点(即，一个或多个MFE)的报告。如下面将更详细描述的，逻辑元件可能被发布到控制平面，但是在实现逻辑实体的一组物理节点中的一个或多个物理节点中没有被实现。即，如上所述，逻辑实体跨越若干不同的物理节点(即，在物理节点上执行的若干不同的MFE)。由此，逻辑实体可能被推送到不同的物理节点，但是没有在物理节点的子集上实现。一些实施例仅报告其上尚未正确实现逻辑实体的物理节点的子集(和/或在节点的子集上执行的MFE)。

在一些实施例中，当管理平面报告尚未实现特定逻辑实体时，这样的报告不一定意味着逻辑实体已经失败(并且例如应该被重新生成)。一些实施例报告在特定时间点没有实现逻辑实体仅仅是因为此时控制平面尚未完成逻辑实体的实现过程。因此，如果用户稍后使用新GRN查询系统，那么之前报告为未实现的相同逻辑实体可能在响应新查询时被显示为已实现。

虽然在上面的示例中，GRN在每次API调用之后(即，在生成每个逻辑实体并将其发布到控制平面之后)递增，但是在一些实施例中，用户可以在创建逻辑实体之后手动递增GRN。例如，当用户做出需要一百个API调用来实现逻辑改变的逻辑改变(例如，将应用供应给数据中心)时，用户将不会对第二十或三十七次调用的实现状况感兴趣。用户最可能对应用的实现状况(即，在进行所有100个API调用之后的实现状况)感兴趣。在这种情况下，代替在每次API调用之后系统递增GRN或与之结合，用户在最后一次API调用之后递增GRN。换句话说，手动递增GRN的动作允许用户接收可用于跟踪逻辑改变的实现状况的GRN值。

如上所述，在一些实施例中，GRN值可以以不同方式递增。在一些实施例中，使用频率(例如，以毫秒定义)周期性地自动递增GRN。在一些这样的实施例中，在每次递增之后，向所有CCP节点发送请求，使得CCP集群可以跟踪由管理平面管理的最新屏障号(即，GRN)。可替代地，或结合地，一些实施例允许GRN的强迫递增(即，手动递增)。即，用户还能够手动递增GRN(例如，使用诸如REST API调用的API调用)。在一些实施例中，为了手动递增GRN并且同时识别最新的GRN值，用户调用特定的GRN递增函数，其递增GRN值并同时将递增后的值返回给用户。

一些实施例在每个期望状态更新之后递增GRN。即，每当接收到用于创建、修改或移除逻辑实体的新API调用时以及在将生成的逻辑实体发送到CCP集群用于实现之后，一些实施例递增GRN。例如，当接收到逻辑交换机的API调用(例如，REST API调用POST/PUT/DELETE)时，在逻辑交换机消息被发布到CCP集群之后，递增GRN并将其发送到控制集群。在这种GRN生成方法中，CCP集群处于基于给定GRN返回逻辑交换机的已实现状态的良好位置。

一些实施例在每个期望状态更新之后递增GRN，但是以与上述方式不同的方式。即，一些实施例在接收到用于创建、修改或移除逻辑实体的新API调用之后并且在将生成的逻辑实体发送到CCP集群用于实现之前立即递增GRN。但是，在这种GRN生成方式中，CCP集群将无法确定所查询的逻辑实体的实现状况，并且因此报告逻辑实体的实现状态正在进行中，或者替代地，逻辑实体尚未实现。一些实施例同时采用两个或更多个上述方法的组合，而在其它实施例中，用户能够(例如，针对每个不同的集群)选择一个或多个GRN生成方法。

在一些实施例中，对于每个API调用，GRN不必恰好递增一次。例如，当两个用户(例如，数据中心的两个租户、同一租户的两个网络管理员等)修改其DFW配置并且然后发出API调用以递增GRN(例如，在阈值时间段内)时，一些实施例仅将GRN值递增一次并将相同的数字返回给两个用户。在一些这样的实施例中，这种类型的松弛允许限制施加在GRN上的并发修改异常。

此外，在一些实施例中，GRN不必是一次包含一个值的变量。在一些实施例中，GRN变量是数字的向量(数组)。例如，一些实施例的GRN是具有用于所有逻辑交换机的一个元素(数字)、用于所有逻辑交换机端口的一个元素、用于所有逻辑路由器的一个元素等的数组。具有值的数组而不是用于GRN的一个单个值在这些实施例中允许更高的并发性，代价是更高的传输成本和稍高的复杂性。

图4图示了在一些实施例中更新(递增)GRN的一种方法。所示方法以某个时间间隔(例如，每10秒)自动更新GRN值。在一些实施例中，每次更新之间的持续时间是可调节的(例如，由网络管理员、运营商等)。该图示出了在不同时刻，管理平面(例如，中央管理平面(CMP)集群)递增GRN并将递增后的值发布到控制平面(例如，CCP集群)，同时一个或多个逻辑实体在这些时刻之间被更新(或者以时间间隔期间不创建或更新逻辑实体)。

如该图所示，在时刻T1，管理平面410将逻辑交换机LS1发布到控制平面420。在时刻T2(例如，T1之后的五秒)，管理平面将具有GRN值1的GRN发布到控制平面。然后，管理平面在时刻T3(例如，T2之后五秒)发布第二逻辑交换机LS2。但是，在发布第二逻辑交换机之后，管理平面不递增GRN，而是如图所示，将逻辑路由器LR(在时刻T4)发布到控制平面。这是因为尚未到达时间T3之后5秒的时间T4处的GRN更新时间(例如，该示例中的时间间隔被设置为每15秒)。

在T4之后5秒的时刻T5，管理平面向控制平面发出GRN的新值G2，这是因为T2(上次更新GRN的时间)与T5之间的时间间隔为15秒，这最初被设定为GRN的发布时间。然后，在时间T6，管理平面410向控制平面420发出对先前创建的逻辑实体(即，逻辑路由器LR)的修改。在时间T7，在控制平面和管理平面之间没有事务。这是因为此时用户或管理平面尚未修改或创建任何逻辑实体，同时，T7只是最后一次GRN更新之后的10秒，并且因此GRN也不应该在这个时刻发布。最后，管理平面410将GRN值递增到G3，并在时刻T8将该新值发布到控制平面420，时刻T8在T5(即，最后一次递增和发布GRN)之后15秒。

如上所述，一些实施例的CCP集群包括一个或多个控制器，其为托管系统(例如，数据中心)的一个或多个租户配置一个或多个逻辑网络。在一些实施例中，CCP集群(1)(例如，从CMP集群)接收定义逻辑网络的数据，(2)从一组MFE接收运行时数据(例如，通过对应的一组本地控制器)，(3)基于接收到的定义和运行时数据，计算为逻辑网络定义一组逻辑转发元件的转发行为的配置和转发数据，以及(4)将计算出的数据分发到在一组主机机器上操作的一组本地控制器。

在一些实施例中，每个本地控制器以及受管理转发元件驻留在执行逻辑网络的一个或多个DCN的主机机器上(例如，在主机机器的虚拟化软件中)。在不同主机机器上执行的逻辑网络的DCN通过一组逻辑转发元件(例如，逻辑交换机、逻辑路由器等)在逻辑上连接到彼此(和连接到其它物理或逻辑网络)。

在一些实施例中，每个本地控制器在从CCP集群接收到逻辑网络数据之后，生成配置和转发数据，该数据定义与本地控制器一起驻留在同一主机机器上的MFE的转发行为。然后，本地控制器将生成的数据分发到在同一主机机器上操作的MFE。MFE基于从本地控制器接收到的配置和转发数据实现一组逻辑转发元件。每个MFE可以连接到若干不同的DCN，其不同的子集可以属于不同租户的不同逻辑网络。由此，MFE能够为不同的逻辑网络实现不同组逻辑转发元件。

图5概念性地图示了中央管理平面集群、中央控制平面集群和托管系统(例如，数据中心)中的一组主机之间的关系。该图示出了中央控制平面(CCP)集群如何从中央管理平面(CMP)集群接收逻辑网络定义(例如，逻辑拓扑)和GRN，并将所需的转发和配置数据发布到一组主机机器。发布的配置和转发数据使得在主机机器上运行的一组受管理转发元件能够配置和实现逻辑网络的逻辑实体(例如，逻辑转发元件)。

图5包括CMP集群515、CCP集群520和两个主机机器535和540。图中所示的主机机器包括受管理转发元件545(即，MFE1-2)和数据计算节点550(即，VM1-4)。在一些实施例中，MFE 545在主机机器535和540的虚拟化软件(例如，管理程序)中实现(为了简化描述，管理程序未在图中示出)。CMP集群515包括一组中央管理器525，而CCP集群520包括一组中央控制器530。每个主机机器还包括本地控制器560，该本地控制器560与MFE 545一起操作(例如，在主机机器的管理程序中)并配置和管理相关联的MFE以实现逻辑网络的逻辑实体。

管理器525和控制器530中的每一个可以是物理计算设备(例如，服务器、计算机等)，数据计算节点(DCN)(诸如虚拟机(VM)、容器等)或者在物理计算设备或DCN上操作的软件实例(或进程)。在一些实施例中，管理器包括用于托管系统中的一个或多个逻辑网络的管理、配置、监视和故障排除的不同用户界面应用。一些实施例的一个或多个控制器的子集控制实现逻辑网络的逻辑元件的不同受管理转发元件(MFE)之间的数据通信。

如上所述，中央控制平面(CCP)集群520通过控制MFE 545之间的数据通信来控制逻辑网络的不同DCN之间(例如，在所示示例中的一些VM 550之间)的网络数据通信。CCP集群520与MFE 545通信以便控制MFE之间的数据交换，因为MFE实现最终在DCN之间交换逻辑网络数据的虚拟隧道端点(VTEP)。为了控制数据交换，一些实施例的CCP集群从每个MFE接收逻辑网络实体(例如，VM 550、逻辑网络的LFE等)的运行时数据。CCP集群520还从CMP集群515接收逻辑拓扑数据，并将定义数据与运行时数据一起使用，以便控制逻辑网络的数据通信。

即，基于(例如，通过本地控制器560)从MFE接收到的运行时数据和从CMP集群接收到的网络定义数据(即，期望状态)，CCP集群生成被推送到MFE并与MFE共享(例如，通过本地控制器560)的一组数据(即，转换/共享状态)。在一些实施例中，CCP集群使用由CCP集群生成和存储的其它数据(例如，分片表)以便生成转换状态。转换状态由MFE使用，以便物理地交换由MFE实现的一个或多个LFE逻辑转发的数据。

在一些实施例中，典型的逻辑网络定义数据包括定义DCN的位置的数据(例如，主机机器上的VM的位置)、定义DCN之间的连接拓扑和拓扑中的LFE的位置的数据、定义应用于LFE的中间盒服务的数据(例如，分布式防火墙策略)等。在一些实施例中，典型的运行时数据包括第2层控制平面表，诸如虚拟隧道端点(VTEP)表、媒体访问控制(MAC)表、地址解析协议(ARP)表；第3层路由表，诸如路由信息库(RIB)表、转发信息库(FIB)表；从MFE等收集到的统计数据，等等。

在一些实施例中，主机机器的每个管理程序的本地控制器560从CCP集群520的中央控制器530接收逻辑网络数据。然后，本地控制器560转换和定制在本地控制器在其上操作的同一机器上操作的本地MFE 545的接收到的逻辑网络数据。然后，本地控制器将转换和定制的数据递送到每个主机机器上的本地MFE 545。在一些实施例中，使用被映射到MFE的物理端口的逻辑端口来定义终端机器与LFE(例如，逻辑交换机)的连接。

如上所述，在一些实施例中，逻辑网络的LFE(逻辑路由器和交换机)由连接到逻辑网络的每个MFE实现。即，在一些实施例中，当MFE从DCN接收到报文时，MFE执行DCN逻辑耦合到其的逻辑交换机的网络转发处理，以及任何附加LFE的处理(例如，如果报文被发送到外部网络，则执行逻辑路由器处理，如果报文被发送到耦合到另一个逻辑交换机的终端机器(DCN)，则执行逻辑路由器处理和网络中另一个逻辑交换机的处理，等等)。CMP集群515生成并发布到CCP集群520的GRN使得系统能够确定MFE实现的逻辑转发元件(和任何其它逻辑实体)是否在MFE中被正确配置。即，GRN使得系统(或用户)能够确定为一个或多个逻辑网络定义的逻辑实体是否在系统中被实现。

本领域普通技术人员将认识到的是，图中所示的主机机器、中央管理器和控制器以及虚拟机的数量是示例性的，并且用于托管系统的租户的逻辑网络可以跨越多个主机机器(和第三方交换机)，并将大量DCN逻辑连接到彼此(以及连接到若干其它物理设备)。此外，虽然在该图和下面的其它图中被示出为VM，但是应该理解的是，在一些实施例中，其它类型的数据计算节点(例如，命名空间、容器等)可以连接到逻辑转发元件。

一些实施例提供世代号(例如，在GRN变量内)以识别群集事件、时间片重新分配、或者何时MP数据库被安装和/或恢复。在一些实施例中，群集事件包括CCP集群中改变集群的当前工作集的任何变化或修改。例如，当CCP集群中的一个控制器崩溃或失去与集群的连接时，发生群集事件。此外，当网络管理员移除现有控制器或将新控制器添加到CCP集群时，会发生群集事件。

当分配给集群的特定控制器的工作时间片被重新分配给另一个控制器时或者通常当分配给控制器的工作时间片发生变化时，发生时间片移动。在一些实施例中，分配给每个控制器的工作负载包括为不同目的执行的不同工作时间片。例如，可以分配控制器来计算属于两个不同逻辑网络的两组不同逻辑实体的配置和转发数据。在类似这种的情况下，控制器在第一工作时间片中计算第一逻辑网络的数据并且在第二不同的工作时间片中计算第二逻辑网络的数据。当控制器上的工作负载变重时，工作分配过程变为活动的并且在一些实施例中将一个或多个工作时间片移动到另一个控制器。因此，即使没有群集事件(即，控制器本身没有变化)，集群上的工作分配也会发生变化，并且因此需要新的世代号。

由于MP存储所有逻辑网络的所有期望状态，因此一些实施例在发生事故的情况下以某个时间间隔备份MP。如果事故确实发生，网络运营商将最新备份的快照复制到MP。这种类型的事件被称为MP数据库的恢复，这也需要新的世代号。因此，在一些实施例中，每次发生群集事件或时间片重新分配时或者每次安装或恢复管理平面数据库时，递增世代号。在一些实施例中，这种递增自动发生(例如，对于每个新的群集事件)。在一些实施例中，用户也可以(手动)递增世代号(例如，当恢复MP数据库的备份版本时)。

在一些实施例中，MP(例如，通过远程过程调用)查询CCP集群以确保在所有CCP节点之间同步世代号。在一些这样的实施例中，每个CCP节点用其最新的世代号回复查询。当所有回复中的世代号不相同时，MP可以断定，最近发生的某些群集变化尚未被CCP节点中的一些处理。在一些实施例中，世代号是与GRN分开的变量。但是，在一些这样的实施例中，每个世代号与GRN相关联。在一些实施例中，通用唯一标识符(UUID)包括世代号和GRN两者(例如，GRN和世代号两者都可以被编码在单个64位UUID中，其中前16位保持世代号并且较低的48位保持GRN)。

在一些实施例中，管理平面向用户提供GRN接口，其允许用户在期望状态版本号(即，GRN)的上下文内查询给定实体(或一组实体)的实现状况。然后，一些这样的实施例的每个CCP节点用实现的状态消息(或者到达超时的消息)回复该查询。当CCP节点中的一个或多个不回复时，一些实施例的管理平面重试预定次数，并且如果仍然没有从CCP节点接收到回复，则返回错误消息或不可用消息(指示哪些CCP节点没有响应)。当CCP节点中的一些不回复用户提交的查询时，一些其它实施例的管理平面向用户的查询返回错误消息或不可用消息。

另一方面，当所有CCP节点响应但是所有回复中的世代号不相同时，一些实施例的管理平面断定最近发生的某种群集变化(例如，群集事件、时间片移动等)尚未被一些CCP节点处理。在一些实施例中，MP用显示用户API调用的实现失败的消息进行响应，而在一些其它实施例中，MP在返回失败的实现消息之前再次查询CCP集群一次或多次。当CCP集群中的世代号相同时，MP可以继续评估从CCP节点接收到的所有响应中的实现状况。

当至少一个实现消息指示不成功时，一些实施例的MP意识到对应的CCP节点尚未处理指定的期望状态版本或对应的运行时状态版本。在这种情况下，MP不查看响应中的MFE状况，并向用户回复实现正在进行(或者对应的控制器尚未处理逻辑实体)。如下面将讨论的，一些实施例的CCP集群节点在查询实现状况时将尚未实现逻辑实体的MFE返回给MP。

在一些实施例中，当来自CCP集群的每个响应中的实现状况指示成功时，一些实施例的MP查看对于其CCP集群已返回不成功实现状况的MFE状况。即，在一些实施例中，从CCP集群接收到的实现状况响应包括一个或多个特定字段，其识别尚未针对期望状态正确实现的MFE。在一些这样的实施例中，当来自CCP集群的回复都没有携带针对任何MFE的不成功实现消息时，MP返回成功实现消息，这意味着直到查询中指定的GRN值为止的所有逻辑实体都被实现并且正确工作。

图6概念性地图示了一些实施例的过程600，其向CCP集群查询特定GRN并基于该过程从CCP集群接收到的响应来报告逻辑实体的实现状况。在一些实施例中，该过程由管理器计算机或在管理器计算机上执行的管理器应用执行。一些这样的实施例的管理器计算机(或应用)为一个或多个用户(例如，数据中心的不同租户)在物理网络基础设施(例如，数据中心网络)上创建和管理一个或多个逻辑网络。

过程600通过向CCP集群的控制器(计算机和/或应用)查询(在610处)与特定GRN值相关联的一个或多个逻辑实体(例如，逻辑交换机、逻辑路由器、逻辑防火墙、逻辑负载平衡器等)的实现状况开始。在一些实施例中，该过程从用户(例如，数据中心的网络管理员)接收查询，其中用户指定应该从CCP集群查询的逻辑实体和GRN值。在一些实施例中，用户仅在查询中指定提交给管理平面的GRN值，并且该过程查询已经创建(和/或修改)并发布到CCP集群的所有逻辑实体的实现状况。

然后，该过程确定(在620处)对查询的响应是否包含在CCP集群上相同的世代号。如上所述，由于CCP集群中的最近变化(例如，群集事件、工作时间片移动等)，一个或多个集群节点可能具有与其它节点不同的世代号。由此，不应该依赖响应中的实现状况。当该过程确定控制器的世代号中存在差异时，一些实施例的过程放弃进一步检查回复并且向用户返回(在625处)失败消息。在一些实施例中，消息不显示实现的失败并且仅指示由于群集事件，查询应该在稍后的时间提交。但是在一些其它实施例中，该过程在返回失败和/或进行中消息之前自动重试查询CCP集群更多的几次(例如，可由用户设定和调整的次数)。在返回消息之后，该过程结束。

当该过程确定(在620处)对查询的响应包含在CCP集群上相同的世代号时，该过程确定(在630处)所有响应中的实现状况是否显示控制器已基于期望状态及其对应的逻辑实体的运行时状态正确计算出配置和转发数据。换句话说，该过程确定每个控制器(1)是否已经处理从管理平面接收到的一个或多个逻辑实体的期望状态以及从MFE接收到的相同逻辑实体的对应运行时状态，并且(2)已将处理后的数据向下推送到MFE(例如，通过MFE的对应本地控制器)以实现逻辑实体。

当该过程确定(在630处)CCP节点中的一个或多个尚未成功处理和分发配置数据时，该过程返回(在635处)仍未处理数据的控制器的报告。一些实施例的过程在报告中指示这些控制器仍处于实现逻辑实体的过程中。在一些实施例中，在返回一些控制器仍在处理数据的消息之前，该过程再次尝试几次来确定是否所有控制器已经实现了逻辑实体。在返回报告之后，该过程结束。

当该过程确定从控制器接收到的所有响应中的实现状况显示控制器已正确计算出配置和转发数据时，该过程确定(在640处)所有响应中的实现状况是否显示本地控制器已基于从CCP集群接收到的配置和转发数据正确配置MFE，以实现逻辑实体。在一些实施例中，每个控制器不仅指示(例如，通过控制器生成的响应的一个或多个字段)控制器已为逻辑实体生成配置数据并将数据推送到对应的MFE，而且还指示(例如，通过响应中生成的一组不同的字段)哪些MFE仍未被配置以实现逻辑实体(如果有的话)。

即，当CCP集群的控制器(从MP)接收到对逻辑实体的实现状况的请求时，控制器首先识别控制器携带的最新世代号并将识别出的世代号插入到对请求的实现响应中。然后，控制器确定控制器是否已经处理从管理平面接收到的逻辑实体定义数据以及从MFE接收到的逻辑实体运行时数据。如果控制器已成功处理这些数据(即，生成逻辑实体的配置和转发数据)并将处理后的数据递送到在一组主机机器上运行的一组对应的本地控制器，则控制器还在实现响应中插入成功消息。

最后，一些实施例的控制器还确定逻辑实体是否已经(由本地控制器)在控制器管理的对应MFE上被成功地配置。当控制器识别出其上尚未配置逻辑实体的一个或多个MFE时，控制器还在实现响应中插入其上尚未配置逻辑实体的MFE(MFE的标识符)。

当该过程确定从一个或多个控制器接收到的一个或多个响应中的传输实现状况显示一些本地控制器仍在配置其对应的MFE时，该过程报告(在645处)一些MFE尚未实现逻辑实体。一些实施例的过程在报告中指示MFE仍处于实现(配置)逻辑实体的过程中。类似于先前的操作，在一些实施例中，在返回一些本地控制器仍在配置MFE的消息之前，该过程再次尝试几次来确定是否所有本地控制器都已在MFE上配置了逻辑实体。在返回报告之后，该过程结束。

另一方面，当该过程确定(在640处)所有响应中的实现状况显示本地控制器已正确配置所有MFE以实现逻辑实体时，该过程返回(在650处)以下消息：在查询到的GRN处的所有逻辑实体已在网络中被成功实现。然后该过程结束。

重要的是要注意到，许多上述操作是基于以下假设来描述的：用户利用GRN值来查询管理平面，该GRN值是在创建和/或修改用户为其查询系统的一组逻辑实体中的最后一个逻辑实体之后用户接收到的。因此，一些操作被描述为返回正在进行(仍在处理数据)的消息。应该理解的是，如果用户利用在逻辑实体的最后一次修改之前生成的较早GRN值来查询系统，则当第一响应指示逻辑实体没有在该较早GRN值处实现时，一些实施例的过程不再做出任何更多的努力来查询CCP集群。

此外，可以不以所示和所描述的确切顺序执行过程600的特定操作。可以不在一个连续操作系列中执行特定操作，并且可以在不同的实施例中执行不同的特定操作。例如，在检查从CCP节点接收到的响应中的世代号之前，一些实施例首先确保所有控制器都已对查询做出响应。当一个或多个CCP节点没有响应查询时，一些这样的实施例返回错误消息。一些其它实施例在短时间内再次查询CCP集群以尝试从每个单个集群节点获得响应。只有在每个集群节点已发送回复之后，这些实施例才开始在响应中检查逻辑实体的世代号和实现状况。最后，本领域普通技术人员将认识到的是，过程600可以使用若干子过程来实现，或者作为更大的宏过程的一部分来实现。

图7图示了在接收到针对直到特定GRN为止的一个或多个逻辑实体的实现状况的查询之后一些实施例的控制平面返回的响应的示例。该图在两个单独的阶段705和710中示出控制平面向CCP集群查询直到GRN的特定值为止已经创建和/或修改的每个逻辑元件的实现状况。该图包括管理器720(例如，在CMP集群中)、两个控制器730(例如，在CCP集群中)以及四个本地控制器740(例如，在四个不同的主机机器(未示出)中)。

在第一阶段705中，管理器710已经提交了对直到GRN＝10已经创建和/或修改的每个逻辑元件的实现状况的请求。管理器查询两个控制器730，它们负责四个本地控制器740在其上操作的四个主机机器(即，主机机器的管理程序)上的逻辑实体的配置。如图所示，CCP集群中的控制器1负责为本地控制器LC1和LC2生成配置和转发数据，而控制器2负责为本地控制器LC3和LC4生成配置和转发数据。每个本地控制器640从CCP集群中其对应的控制器接收数据，该数据定义了在与本地控制器相同的管理程序上操作的MFE的公共转发行为。然后，每个本地控制器生成特定于其对应的MFE的配置和转发数据，以便实现逻辑实体并将生成的定制数据传递给MFE。

第二阶段显示两个控制器730将两个不同的世代号(即，Gen#2和Gen#3)返回给管理器720。如前面所讨论的，在管理器从CCP集群接收到的响应中具有不同的世代号可能有不同的原因。例如，由于CCP集群中的最近变化(例如，群集事件、工作时间片移动等)，一个或多个集群节点可能具有与其它节点不同的世代号。由此，当管理器720意识到从CCP集群接收到的世代号中存在差异时，管理器停止进一步查看从CCP集群接收到的响应来识别实现状况。一些这样的实施例的管理器返回失败消息，或者替代地，向用户报告已经发生最近的群集事件并且用户需要在稍后的时间查询逻辑实体的实现状况。

如上所述，一些实施例的CCP集群(例如，CCP集群中的一个或多个CCP节点)返回用于逻辑实体的实现状况的消息(响应于逻辑实体的实现状态查询)。在一些实施例中，返回的消息可以是成功消息、不成功消息或进行中消息。在一些实施例中，成功状况指示CCP集群已处理接收到的期望状态并将处理后的数据推送到本地控制平面(例如，在同一主机机器中与MFE一起操作的一个或多个本地控制器)。在一些实施例中，每当MP递增GRN时，MP将递增后的GRN与CCP集群同步。在一些实施例中，控制器节点之一(例如，分片主控制器)将相同的GRN分配给保持在CCP集群的控制器处的当前运行时状态。在一些实施例中，当CCP集群已经处理特定GRN值的逻辑实体的期望状态和对应运行时状态时，认为GRN的特定值的实现状况是成功的。

在一些实施例中，成功消息不仅指示逻辑实体的期望状态(以及对应的运行时状态)已经由CCP集群处理和发布，而且还指示逻辑实体已在实现逻辑实体的(在主机机器或网关上操作的)一个或多个MFE上被成功配置。例如，在一些这样的实施例中，对逻辑交换机的已实现状态的成功响应意味着(例如，在一个或多个主机机器的管理程序上)实现逻辑交换机的一个或多个MFE成功地连接到一个或多个虚拟机器，该一个或多个虚拟机器逻辑上连接到逻辑交换机。它还意味着MFE与逻辑交换机的控制平面(例如，逻辑交换机的主控制器)和管理平面(例如，逻辑交换机的主管理器)有活动通信。

在一些实施例中，每当MP递增GRN时，MP将递增后的GRN与CCP集群同步。在一些实施例中，控制器节点之一(例如，集群中的分片控制器)将相同的GRN分配给从MFE接收到的逻辑实体的并保持在CCP集群的控制器处的当前运行时状态。在一些实施例中，当CCP集群已经处理特定GRN值处的逻辑实体的期望状态和逻辑实体的对应运行时状态时，认为针对GRN的特定值的逻辑实体的CCP实现状况是成功的。

在一些实施例中，对于逻辑实体的状况的不成功实现响应可能具有不同的原因。例如，当一个或多个CCP节点在处理期望状态更新中落后时，CCP节点可能返回期望状态的不成功实现。对于逻辑实体的期望状态的不成功实现的其它原因包括，当一个或多个MFE明确指示它们未能针对GRN的特定值实现一些变化时、当一个或多个MFE在跟上期望状态更新频率中落后时、当一些MFE长时间断开连接时，等等。

一些实施例提供故障诊断数据以帮助识别期望状态的实现中的各种问题的来源。一些实施例基于识别出的问题的性质和位置为有问题的逻辑实体提供不同级别的细节。一些实施例提供关于未能被实现的特定逻辑元件的故障诊断数据。

图8图示了在接收到针对特定GRN处的一个或多个逻辑实体的实现状况的查询之后一些实施例的控制平面返回的响应的另一个示例。该图在树分离阶段805、810和815中示出控制平面向CCP集群查询直到GRN的特定值为止已经发布到控制平面的特定逻辑元件的实现状况。该图包括管理器720(例如，在CMP集群中)、两个控制器730(例如，在CCP集群中)、四个本地控制器740和四个MFE 820，其中每一个与本地控制器之一相关联(即，本地控制器及其相关联的MFE都在单独的主机机器的管理程序中操作)。

在第一阶段805中，管理器710已经提交了对在GRN＝20处的逻辑交换机LS1的实现状况的请求。管理器查询两个控制器730，它们负责实现逻辑交换机LS1的MFE 820上的逻辑交换机LS1的配置。但是，如图所示，只有MFE2-4实现逻辑交换机LS1。即，每个主机机器上的一组终端机器耦合到的LS1的逻辑端口仅在MFE2、MFE3和MFE4中实现。换句话说，LS1的这些逻辑端口将驻留在MFE2在其上执行的主机机器上的一组终端机器逻辑上连接到驻留在MFE3和MFE4在其上执行的主机机器上的其它终端机器。另一方面，MFE1实现逻辑交换机LS2和逻辑路由器LR1。

第一阶段还示出了在该时间点(即，GRN＝20)，两个控制器730上的世代号是相同的，这意味着CCP节点(关于最新的群集事件)是同步的并且因此实现确定过程可以继续。此外，该图示出CCP集群中的控制器1负责为本地控制器LC1和LC2生成LS1、LS2和LR1的配置和转发数据，而CCP集群中的控制器2负责为本地控制器LC3和LC4生成LS1的配置和转发数据。虽然在所示示例中，两个控制器730都生成并分发逻辑交换机LS1的逻辑配置和转发数据，但是在一些实施例中，CCP集群的每个控制器负责配置特定的一组逻辑实体(即，在一些实施例中，两个CCP节点不同时管理相同的逻辑实体)。

第二阶段示出由于MFE1没有实现逻辑交换机LS1，因此CCP集群不查询与该MFE(即，LC1)相关联的本地控制器，并且因此该本地控制器不向CCP集群发送要转发到管理平面的响应。换句话说，在每个特定GRN处，每个控制器730知道控制器已经处理并向下推送到不同MFE的逻辑元件。即，每个控制器知道控制器管理哪些MFE以及哪些逻辑元件在控制器管理的哪些MFE上实现。因此，当用户请求在特定GRN(即，GRN＝20)处的期望逻辑实体(即，在这个示例中为LS1)的实现状况时，控制器730仅请求直到G＝20为止LS1的配置数据被推送到的MFE的实现状况。

第二阶段还示出了在请求发送逻辑交换机LS1的实现状况的三个本地控制器中，本地控制器LC2和LC4通过将直到GRN＝20为止的逻辑交换机的状况返回为已实现来响应，并且本地控制器LC3通过将LS1的状况返回为(尚)未实现来响应。在MFE3上逻辑交换机LS1的不成功实现的原因可能是控制器LC3在生成用于在MFE3上配置LS1的定制数据中落后。另一个原因可能是控制器2在LS1的配置数据的生成和递送到本地控制器LC3中落后。但是，如下面在第三阶段中所述，该控制器在控制器上实现逻辑交换机时发送成功消息，其指示控制器2在该示例中没有落后。

在第三阶段中，每个控制器730在实现逻辑交换机LS1时发送成功消息(在对查询的响应中)，但是，控制器2的成功消息(例如，在消息的一个或多个字段中)包含仍在处理GRN＝20处的LS1的配置数据的本地控制器。另一方面，控制器1在它返回到管理器720的成功消息中没有任何本地控制器。管理器720基于它从CCP集群接收到的消息能够确定逻辑实体的实现在哪个级别没有成功。即，当CCP集群的两个控制器都返回成功消息时，管理器断定逻辑交换机LS1在CCP集群中实现(即，交换机的配置数据已被处理并且推送到本地控制器)。但是，当CCP节点中的一个或多个在其消息中指示一些MFE尚未实现逻辑元件时，管理器可以识别针对查询的逻辑实体(直到GRN＝20)仍在处理数据的MFE和主机机器。

许多上述特征和应用被实现为软件过程，这些软件过程被指定为记录在计算机可读存储介质(也被称为计算机可读介质)上的一组指令。当这些指令由一个或多个计算或处理单元(例如，一个或多个处理器、处理器核或其它处理单元)执行时，它们使得该(一个或多个)处理单元执行在指令中指示的动作。计算机可读介质的示例包括但不限于CD-ROM、闪存驱动器、随机存取存储器(RAM)芯片、硬盘驱动器、可擦除可编程只读存储器(EPROM)、电可擦除可编程只读存储器(EEPROM)等。计算机可读介质不包括无线或通过有线连接传递的载波和电子信号。

在本说明书中，术语“软件”是指包括驻留在只读存储器中的固件或者可以被读入到存储器中用于由处理器处理的存储在磁存储装置中的应用。此外，在一些实施例中，多个软件发明可以被实现为更大程序的子部分，同时保持明显的软件发明。在一些实施例中，多个软件发明也可以被实现为单独的程序。最后，一起实现本文所描述的软件发明的单独程序的任意组合在本发明的范围内。在一些实施例中，当软件程序被安装，以在一个或多个电子系统上操作时，软件程序定义运行并执行软件程序的操作的一个或多个特定的机器实现。

图9概念性地图示了实现本发明的一些实施例的电子系统900。电子系统900可以是计算机(例如，台式计算机、个人计算机、平板计算机等)、服务器、专用交换机、电话、PDA或任何其它种类的电子或计算设备。这样的电子系统包括各种类型的计算机可读介质和用于各种其它类型的计算机可读介质的接口。电子系统900包括总线905、(一个或多个)处理单元910、系统存储器925、只读存储器930、永久存储设备935、输入设备940和输出设备945。

总线905统一地表示通信地连接电子系统900的许多内部设备的所有系统、外围设备和芯片组总线。例如，总线905将(一个或多个)处理单元910与只读存储器930、系统存储器925和永久性存储设备935通信地连接。

(一个或多个)处理单元910从这些各种存储器单元检索要执行的指令和要处理的数据，以便执行本发明的过程。在不同实施例中，(一个或多个)处理单元可以是单个处理器或多核处理器。

只读存储器(ROM)930存储由(一个或多个)处理单元910和电子系统的其它模块所需的静态数据和指令。另一方面，永久性存储设备935是读写存储器设备。该设备是即使当电子系统900关闭时也存储指令和数据的非易失性存储器单元。本发明的一些实施例使用大容量存储设备(诸如磁盘或光盘及其相应的盘驱动器)作为永久性存储设备935。

其它实施例使用可移除存储设备(诸如软盘、闪存存储器设备等及其对应的驱动器)作为永久性存储设备。与永久性存储设备935一样，系统存储器925是读写存储器设备。但是，与存储设备935不同的是，系统存储器925是易失性读写存储器，诸如随机存取存储器。系统存储器925存储处理器在运行时所需的一些指令和数据。在一些实施例中，本发明的过程存储在系统存储器925、永久性存储设备935和/或只读存储器930中。(一个或多个)处理单元910从这些各种存储器单元检索要执行的指令和要处理的数据，以便执行一些实施例的过程。

总线905还连接到输入和输出设备940和945。输入设备940使用户能够向电子系统传达信息和选择命令。输入设备940包括字母数字键盘和指示设备(也称为“光标控制设备”)、相机(例如，web摄像头)、麦克风或类似设备，用于接收语音命令等。输出设备945显示由电子系统生成的图像或以其它方式的输出数据。输出设备945包括打印机和显示设备，诸如阴极射线管(CRT)或液晶显示器(LCD)，以及扬声器或类似的音频输出设备。一些实施例包括用作输入和输出设备两者的设备，诸如触摸屏。

最后，如图9所示，总线905还通过网络适配器(未示出)将电子系统900耦合到网络965。以这种方式，计算机可以是计算机的网络(诸如局域网(“LAN”)、广域网(“WAN”)或内联网)的一部分，或者是网络的网络，诸如互联网。电子系统900的任何或所有组件可以与本发明结合使用。

一些实施例包括电子组件，诸如微处理器、在机器可读或计算机可读介质(可替代地称为计算机可读存储介质、机器可读介质或机器可读存储介质)中存储计算机程序指令的存储装置和存储器。这种计算机可读介质的一些示例包括RAM、ROM、只读压缩盘(CD-ROM)、可记录压缩盘(CD-R)、可重写压缩盘(CD-RW)、只读数字多功能盘(例如，DVD-ROM、双层DVD-ROM)、各种可记录/可重写DVD(例如，DVD-RAM、DVD-RW、DVD+RW等等)、闪存存储器(例如，SD卡、小型SD卡、微型SD卡等)、磁和/或固态硬盘驱动器、只读和可记录Blu-

盘、超密度光盘、任何其它光或磁介质、以及软盘。计算机可读介质可以存储可由至少一个处理单元执行的并且包括用于执行各种操作的指令集的计算机程序。计算机程序或计算机代码的示例包括诸如由编译器产生的机器代码，以及包括由计算机、电子组件、或使用解释器的微处理器执行的更高级代码的文件。

虽然以上讨论主要涉及执行软件的微处理器或多核处理器，但是一些实施例由一个或多个集成电路来执行，诸如专用集成电路(ASIC)或现场可编程门阵列(FPGA)。在一些实施例中，这种集成电路执行存储在电路自身上的指令。此外，一些实施例执行存储在可编程逻辑器件(PLD)、ROM或RAM器件中的软件。

如本说明书和本申请的任何权利要求中所使用的，术语“计算机”、“服务器”、“处理器”和“存储器”都是指电子或其它技术设备。这些术语不包括人或人群。为了本说明书的目的，术语显示或正在显示意味着在电子设备上显示。如在本说明书和本申请的任何权利要求中所使用的，术语“计算机可读介质”、“多个计算机可读介质”和“机器可读介质”被完全限制为以由计算机可读的形式存储信息的、有形的、物理的对象。这些术语不包括任何无线信号、有线下载信号以及任何其它短暂信号。

贯穿本说明书提到包括虚拟机(VM)的计算和网络环境。但是，虚拟机只是数据计算节点(DCN)或数据计算终端节点(也被称为可寻址节点)的一个示例。DCN可以包括非虚拟化物理主机、虚拟机、在主机操作系统之上运行而不需要管理程序或单独的操作系统的容器、以及管理程序内核网络接口模块。

在一些实施例中，VM使用由虚拟化软件(例如，管理程序、虚拟机监视器等)虚拟化的主机的资源与主机上其自己的客户操作系统一起操作。租户(即，VM的所有者)可以选择在客户操作系统之上要操作哪些应用。另一方面，一些容器是在主机操作系统之上运行而不需要管理程序或单独的客户操作系统的构造。在一些实施例中，主机操作系统使用命名空间来将容器彼此隔离，并因此提供在不同容器内操作的不同应用组的操作系统级分离。这种分离类似于在虚拟化系统硬件的管理程序虚拟化环境中提供的VM分离，并且因此可以被视为隔离在不同容器中操作的不同应用组的一种虚拟化形式。这种容器比VM更轻巧。

在一些实施例中，管理程序内核网络接口模块是包括具有管理程序内核网络接口和接收/传送线程的网络堆栈的非-VM DCN。管理程序内核网络接口模块的一个示例是作为VMware公司的ESXi^TM管理程序的一部分的vmknic模块。

应当理解的是，虽然本说明书提到VM，但是给出的示例可以是任何类型的DCN，包括物理主机、VM、非-VM容器和管理程序内核网络接口模块。事实上，在一些实施例中，示例网络可以包括不同类型的DCN的组合。

此外，在整个本申请中使用术语“报文”来指代跨网络发送的特定格式的位的集合。应该理解的是，术语“报文”在本文中可以用于指代可以跨网络发送的各种格式化的位的集合。这种格式化的位的集合的几个示例是以太网帧、TCP段、UDP数据报、IP报文等。

虽然本发明已经参考许多特定细节进行了描述，但是本领域普通技术人员将认识到的是，在不脱离本发明的精神的情况下，本发明可以以其它特定形式体现。此外，多个图(包括图6)概念性地图示了过程。这些过程的特定操作可能没有以与所示出和描述的确切顺序执行。特定操作可能没有在一系列连续的操作中执行，并且不同的特定操作可能在不同的实施例中执行。此外，过程可以利用若干子过程来实现，或者作为更大的宏过程的一部分来实现。因此，本领域普通技术人员将理解的是，本发明不受上述说明性细节的限制，而是由所附权利要求来限定。

Claims (20)

1.一种用于确定逻辑网络的一个或多个逻辑实体的实现状况的方法，所述方法包括：

在由管理所述逻辑网络的管理器计算机接收到指定所述逻辑网络的逻辑实体的期望状态的数据后，将期望状态发布到一组控制器，所述一组控制器将所述期望状态发布到实现所述逻辑网络的一组受管理转发元件MFE；

每次发生特定事件时就：

递增实现号，所述实现号的每个值指示特定时间；以及

将递增后的实现号发布到所述一组控制器，其中所述一组控制器存储包括期望状态的实现状况和实现号的每个发布的值的发布次序；以及

使用实现号的特定值向所述一组控制器查询一组期望状态的实现状况，其中所述一组控制器使用所述发布次序来确定在实现号的特定值的发布之前发布的每个期望状态是否已被分发给所述一组受管理转发元件。

2.如权利要求1所述的方法，其中，每次发生所述特定事件时就递增实现号包括以某些时间间隔自动递增实现号。

3.如权利要求1所述的方法，其中，每次发生所述特定事件时就递增实现号包括每次从用户接收到递增实现号的新请求时就递增实现号。

4.如权利要求1所述的方法，其中，每次发生所述特定事件时就递增实现号包括每次期望状态被发布到所述一组控制器时就递增实现号。

5.如权利要求1所述的方法，其中，接收到的逻辑实体的期望状态数据包括从用户接收到的逻辑实体的定义。

6.如权利要求1所述的方法，其中，接收到的逻辑实体的期望状态数据包括存储在管理平面数据库的逻辑实体的期望状态，而逻辑实体的已实现状态存储在所述一组控制器处。

7.如权利要求6所述的方法，其中，逻辑实体的已实现状态包括在所述一组MFE上配置逻辑实体以便所述MFE实现逻辑实体所需的配置数据。

8.如权利要求7所述的方法，其中，当所述一组控制器中的每个控制器基于逻辑实体的期望状态和控制器从MFE的子集接收到的逻辑实体的运行时状态生成配置数据时，逻辑实体被实现。

9.如权利要求7所述的方法，其中，逻辑实体在所述一组控制器中的特定控制器执行以下时被实现：(i)基于逻辑实体的期望状态和所述特定控制器从MFE的子集接收到的逻辑实体的运行时状态生成配置数据，以及(ii)将配置数据分发到一组本地控制器，其中每个本地控制器与MFE的子集中的MFE一起在主机机器上操作。

10.如权利要求9所述的方法，其中，每个本地控制器从所述特定控制器接收配置数据并生成特定于MFE的配置数据，所述MFE与本地控制器一起操作以在所述MFE上配置逻辑实体。

11.如权利要求9所述的方法，其中，逻辑实体包括逻辑转发元件，所述逻辑转发元件将在第一主机机器上执行的第一数据计算节点逻辑上连接到在第二主机机器上执行的第二数据计算节点。

12.如权利要求11所述的方法，其中，在第一主机机器上操作的第一MFE从第一数据计算节点接收数据报文，为逻辑转发元件对数据报文执行转发处理功能，并将数据报文转发到在第二主机机器上操作的第二MFE。

13.如权利要求1所述的方法，还包括接收对查询的响应，其中所述响应指示在实现号的所述特定值的发布之前已发布其期望状态的特定逻辑实体尚未被实现。

14.如权利要求13所述的方法，其中，当逻辑实体的期望状态尚未被分发到所述一组MFE时，特定期望状态未被实现。

15.如权利要求1所述的方法，还包括接收对查询的响应，其中所述响应指示在实现号的所述特定值的发布之前已发布的每个期望状态已被成功实现。

16.如权利要求1所述的方法，其中所述一组期望状态包括一组沿着逻辑路径的逻辑实体的期望状态。

17.如权利要求1所述的方法，其中所述一组期望状态包括逻辑转发元件和所述逻辑转发元件的多个逻辑端口。

18.一种存储程序的计算机可读介质，所述程序在被至少一个处理单元执行时实现如权利要求1-17中任一项所述的方法。

19.一种电子设备，包括：

一组处理单元；以及

存储程序的机器可读介质，所述程序在被所述处理单元中的至少一个执行时实现如权利要求1-17中任一项所述的方法。

20.一种用于确定逻辑网络的一个或多个逻辑实体的实现状况的系统，所述系统包括用于实现如权利要求1-17中任一项所述的方法的装置。

Images