CN110383765B - 使用图形模型的计算机基础结构的配置、遥测和分析 - Google Patents

Abstract

公开了一种用于配置计算基础结构的方法。该方法包括将计算基础结构的至少一部分表示为包括计算基础结构节点和计算基础结构边缘的计算基础结构元素的图形表示，检测计算基础结构元素的图形表示中的改变，以及确定该改变是否影响图形表示查询模式。如果该改变影响图形表示查询模式，则将该改变通知给与图形表示查询模式相关联的查询代理。

Description

使用图形模型的计算机基础结构的配置、遥测和分析

其他申请的交叉引用

本申请要求2017年1月24日提交的题为CONFIGURING A COMPUTERINFRASTRUCTURE USING GRAPH MODEL PATTERNS的美国临时专利申请No. 62/449,877的优先权，该申请通过引用结合于本文中以用于所有目的。

背景技术

为了配置和证实（validate）网络的操作状态，网络管理员可以指定期望的网络配置的声明性要求和操作状态的预期。例如，网络管理员可以指定最终网络配置应该是什么的声明性要求，而不是如何完成网络配置的机制。这些声明性要求通常必须包括特定类型的要求，这些要求特定于要创建的特定类型的网络架构。然而，在许多情况下，网络管理员可能期望能够灵活地利用不同的网络架构来提供期望服务的要求。例如，不是将用户限制成已被预先配置成能够实现的单一类型的网络架构，用户可能期望容易地改变和实现新的/不同的网络架构以提供要求的服务。附加地，随着要求随时间的推移而改变，通常必须再次以其整体实行整个计算成本高昂的配置网络的流水线过程以实现改变，不管改变有多么微小。因此，存在对更灵活的方式来指定期望服务的意图的需要。

附图说明

在以下详细描述和附图中公开了本发明的各种实施例。

图1是图示了网络管理环境的实施例的示图。

图2是图示了用于公布网络要求的过程的实施例的流程图。

图3A是图示了用于使用所接收到的声明性要求自动配置网络的示例过程的实施例的流程图。

图3B是图示了用于自动配置L3 Clos网络的示例过程的处理阶段/级别的框图。

图4是图示了用于生成原生硬件指令的过程的实施例的流程图。

图5是图示了用于生成验证模型的过程的实施例的流程图。

图6是图示了用于检测状态参数的过程的实施例的流程图。

图7是图示了用于分析验证报告的过程的实施例的流程图。

图8是图示了用于使用图形模型自动配置计算基础结构的过程的实施例的流程图。

图9是图示了可以被包括在图形模型中的节点和边缘的实施例的框图。

图10A是图示了网络设备的实施例的示图。

图10B是图示了图形模型的一部分的实施例的示图。

图10C是触发模式的示例。

图10D是触发模式的示例。

图11示出了图形模型的模型大纲（schema）（例如，以Python格式）的示例。

图12A是图示了代理（agent）创建流程的实施例的流程图。

图12B是图示了用以检测和响应异常的过程的实施例的流程图。

图13A是图示了包括分支的图形模型的一部分的实施例的示图。

图13B示出了代理的实现方式的示例。

图14A是图示了图形模型的一部分的实施例的示图。

图14B示出了代理的实现方式的示例。

图15是图示了用于调用回调函数的过程的实施例的流程图。

图16是图示了管理服务器的实施例的示图。

具体实施方式

本发明可以用众多方式实现，该方式包括作为过程；装置；***；物质的组成；计算机程序产品，其被体现在计算机可读存储介质上；和/或处理器，例如被配置成执行被存储在耦合到处理器的存储器上和/或由耦合到处理器的存储器提供的指令的处理器。在本说明书中，可以将这些实现方式或本发明可以采取的任何其它形式称为技术。一般而言，可以在本发明的范围内更改所公开过程的步骤的次序。除非另行陈述，被描述为被配置成实行任务的诸如处理器或存储器之类的组件可以被实现为被暂时地配置成在给定时间实行任务的通用组件或被制造成实行该任务的专用组件。如本文中使用的，术语“处理器”指代被配置成处理数据（诸如计算机程序指令）的一个或多个设备、电路和/或处理核心。

下面连同图示了本发明的原理的附图一起提供对本发明的一个或多个实施例的详细描述。结合这样的实施例来描述本发明，但是本发明并不限于任何实施例。本发明的范围仅受权利要求限制，并且本发明涵盖众多替换方案、修改和等同物。在以下描述中阐述了众多具体细节，以便提供对本发明的透彻理解。出于示例的目的提供这些细节，并且可以在没有这些具体细节中的一些或全部的情况下根据权利要求实践本发明。为了清晰起见，在与本发明相关的技术领域中已知的技术材料并未被详细描述，以免不必要地模糊本发明。

企业数据中心基础结构（例如，网络）不断增长，并且对整体管理软件的要求是至关重要的。然而，由于多种多样的网络拓扑结构、不断增长的数据中心大小以及更多的互连数据中心，管理工具尚无法跟上日益复杂的基础结构。将可扩展性构建到管理工具中通常很困难，因为它依赖于具有在客户站点可扩展的可缩放的运行时间和编程环境。例如，许多管理工具不允许扩展内置域模型来表示更新的（newer）基础结构设计。

在一些实施例中，图形表示数据模型（例如，具有节点和边缘）与管理工具一起用来配置和设置计算基础结构的操作状态预期。如下，图形模型、图形表示和图形可以被互换地用来指代图形表示数据模型。图形表示允许使用一小组基础构造（节点和边缘关系）来对丰富度建模。利用图形表示的管理工具是用以缩减建模的复杂性、允许创建用于表示特定网络设计/拓扑结构的域特定的数据模型的一种深度可扩展且有效的方式。

但是使用图形表示带来了新的挑战。随着图形表示的修改的大小和频率增加，实现和维护业务逻辑方面所需的处理也呈指数增长。这些维度使常规的编程范例在递送可靠的基础结构方面处于危险之中。因此，期望实现高效、模块化和可缩放的图形表示模型。

公开了计算基础结构的操作状态的配置和证实。所公开的方法包括将计算基础结构的至少一部分表示为包括计算基础结构节点和计算基础结构边缘的计算基础结构元素的图形表示，检测计算基础结构元素的图形表示中的改变，以及确定该改变是否影响图形表示查询模式。如果该改变影响图形表示查询模式，则向与图形表示查询模式相关联的查询代理通知该改变。在一些实施例中，也在图形表示中表示业务规则和策略。公开了一种包括接口和被配置为执行该方法的处理器的***。

例如，***资源被配置成启用期望的计算机网络配置。在一些实施例中，计算了操作状态必须满足的预期。在一些实施例中，计算基础结构的至少一部分被表示为包括计算基础结构节点和计算基础结构边缘的计算基础结构元素的图形表示。例如，基于所接收到的期望网络配置的声明性要求，生成并利用期望网络配置的计算基础结构元素的图形表示来触发和构建期望网络的配置。节点可以表示的组件的示例包括服务器、交换机、网络接口、虚拟网络、虚拟网络端点、规则、策略等，其中相关联的属性和边缘表示节点和其相关联的属性之间的连接。通过使用图形表示，计算基础结构元素的配置和结构可以被组织成谨慎的对象和相关联的连接，其允许容易地检测任何改变和受该改变影响的关系。

图形表示可以随着要求改变而改变，并且更新了与图形表示元素相关联的属性。在一些实施例中，检测了图形表示中的改变，并且确定该改变是否影响触发图形表示模式。例如，实行处理的处理代理各自与触发相关联代理的处理的一个或多个触发模式相关联。如果检测到的改变影响了处理代理的触发模式，则将该改变报告给与该触发模式相关联的代理。例如，不是利用单个流水线过程来配置和实现整组声明性要求，而是以组合的形式来利用实行了配置和实现方式的不同指派部分的许多不同代理。通过将处理划分为由各种不同代理处理的部分，可以通过仅调用与实现改变相关的特定代理而不是激励整个单片（monolithic）流水线过程来实现微小改变来实现对声明性要求的改变。每个代理与触发模式相关联，该触发模式标识将触发代理的处理的感兴趣图形表示的一部分。如果图形表示包括与代理的触发模式相匹配的至少一部分（例如，对声明性要求的改变改变了与为代理指定的触发模式相匹配的图形表示部分），则调用匹配代理的处理函数以允许处理函数来实行与匹配图形表示部分相关联的处理。

图1是图示了网络管理环境的实施例的示图。管理服务器102经由网络110连接到数据存储104、网络设备106和网络设备108。在一些实施例中，管理服务器102提供网络配置、监控和管理解决方案。例如，用户可以利用由管理服务器102至少部分地提供的解决方案来设置网络配置、设置网络设备、计算操作状态预期、监控网络的性能或操作状态、监控网络的设备、自动化任务、以及以其他方式实行网络的设备的管理。在所示的示例中，利用管理服务器102来管理至少网络设备106和网络设备108。管理服务器102处理/执行代理（例如，实行在图形表示的一部分与对应代理的指定触发图形表示模式相匹配时触发的函数的代理）。在一些实施例中，管理服务器102是专用定制硬件。在一些实施例中，利用管理服务器102来配置硬件网络交换机。

在一些实施例中，管理服务器102促进与用户的交互以接收并提供期望的要求、规范（specification）和状态更新。例如，用户利用直接和/或远程（例如，经由显示器、有线连接、网络等）提供的用户接口（例如，web接口、应用接口、命令行接口、应用编程接口（API）、配置文件接口等）。使用用户接口，用户可以提供指定了期望网络/设备的期望配置的高级要求和/或接收关于期望网络的设备/组件的状态的信息和/或关于期望配置要求的实现状态。

在一些实施例中，管理服务器102在多个处理代理当中选择处理代理（例如，由匹配图形表示的至少一部分的模式触发的），以实现/完成期望的网络要求。在一些实施例中，用户经由API（例如，RESTful API）来访问代理。例如，利用HTTP方法（例如，GET、PUT、POST、DELETE等）来经由API访问和管理信息。可以利用URI来引用状态和资源。可以在多个阶段/级别当中的一个或多个所选阶段/级别处指定声明性要求。在一些实施例中，用户指定期望网络配置的一个或多个约束（例如，资源、策略等）。

在一些实施例中，用以实现声明性要求的计算基础结构的至少一部分被表示为包括计算基础结构节点和计算基础结构边缘的计算基础结构元素的图形模型/表示。与图形表示的每个节点相关联的数据的示例包括：标识符、节点类型（例如，服务器、交换机、接口、规则、策略等）、描述性标记（例如，节点的描述）、标签、以及其他属性（例如，一个或多个键值对）。与图形模型的每个边缘相关联的数据的示例包括：标识符、边缘类型（例如，托管接口、托管在其上等）、由边缘连接的源节点、由边缘连接的目标节点、描述性标记（例如，边缘的描述）、标签、以及其他属性（例如，一个或多个键值对）。

当检测到计算基础结构元素的图形表示中的改变时，确定该改变是否影响任何触发图形表示模式。如果该改变影响触发模式，则将该改变通知给与受影响的触发模式相关联的处理代理。例如，处理代理利用一组具有相关联的回调函数的一个或多个触发模式以声明方式授权。每个代理的函数可以实行生成配置和部署计算基础结构所需的处理的部分。例如，各种代理的回调函数实行语义证实（semantic validation）、收集遥测和执行数据、和/或在执行期间检测异常。

每当图形表示元素的对应的代理触发模式在图形表示的相关联的部分中被“添加”、“更新”和/或“移除”时，***就调用代理的回调。因此，每个代理正在处理与其自身目标相关的图形模型/表示的子集，并且不会因与其无关的改变而调用它。每个处理代理仅关注与其实现的业务逻辑相关的图形表示的部分。代理不需要跟踪对图形的全部改变，并且仅需要基于感兴趣的图形表示部分中的增量改变来重新执行其业务逻辑的部分。通过将与计算基础结构相关的全部处理实现为图形模型的代理，可以在给定处理代理的分散化（decentralization）的情况下独立于任何复杂的中央处理来优化和缩放计算基础结构。

以上述方式编码的代理因此可以递增地实行其职责。在一些实施例中，在启动时，代理评估其输入和输出，并且实行初始处理以确保输入和输出满足其业务逻辑中定义的约束。该初始处理可以涉及处理与代理的定义触发模式相匹配的图形的多个组成部分。在初始启动处理之后，该代理已达到稳定状态。在稳定状态下，代理可以选择仅对与其业务逻辑相关的图形表示的增量改变做出反应，并且在稳定状态之上对这样的改变实行增量处理。

在一些实施例中，处理代理的触发模式指定图形表示元素的标识符，其描述感兴趣的图形表示的至少一部分，并且当触发模式匹配感兴趣的图形表示的一部分或不再匹配图形表示的先前匹配的部分时，执行相关联的处理函数。向代理的调用函数提供指向被包括在匹配部分中的图形表示元素的指针，以允许调用的函数利用/修改相关联的图形表示元素。在一些实施例中，提供API以允许经由API修改和使用图形表示。API的执行调用一个或多个相关联的代理来实行实现API调用的期望结果所需的必要处理。在一些实施例中，在使用和执行计算基础结构期间收集的遥测数据被映射到对应的图形表示元素，以用图形表示格式来（例如，在视觉上）提供遥测数据的表示。

该范例可以支持被用于授权代理的任何编程语言。代码执行是有效的，因为每条代码仅与感兴趣的图形表示的一部分（例如，小部分）明确地相关联，并且仅在必要时被调用。代理也是模块化的，因为每个代理可以具有任意数量的规则，每个规则都具有回调函数，从而沿着触发模式的边界干净地分离代码。它也是可缩放的，因为可以有多个代理实例和多个***来向感兴趣的代理分派改变。这使得能够在基于图形的实时查询之上实现基于实时状态（例如，不是消息）的公布/订阅通信机制，因此能够对增量图形改变和触发增量处理做出反应。***的异步、反应能力允许***缩放。可以轻松添加对现代基础结构平台提供的新特性的支持（例如，通过添加新代理）。在一些实施例中，***的组件反应于意图的改变而进行通信。

管理服务器102实现和管理各种图形表示处理代理。在一些实施例中，代理向被管理的网络的各种设备提供设备要求指令并从其接收状态信息。例如，使用期望的网络要求，代理确定个体设备要求以实现期望的网络要求。在一些实施例中，在将期望的网络要求转换为设备要求时，可以利用多个不同的连续处理阶段/级别。可以为任何不同的处理阶段级别指定网络要求。例如，可以在最一般和最高级别处和/或在较低和更具体的阶段/级别处指定网络要求。每个处理阶段/级别可以将输入声明性要求转换为输出声明性要求，该输出声明性要求可以被用作下一个后续较低处理阶段/级别的输入声明性要求。对于每个处理阶段/级别，代理将输入声明性要求与一个或多个约束（例如，可用资源、要遵循的策略等）合并以确定输出声明性要求。通过能够提供多个不同处理阶段/级别的任何所选阶段/级别的期望声明性网络要求，可以给予用户选以调整用户在配置网络时所期望的控制级别/量。例如，期望快速建立默认配置网络的网络管理员可以在最高阶段/级别处指定声明性要求，而期望建立更加定制和特定的网络的网络管理员可以在较低阶段/级别处指定声明性要求。在一些实施例中，每个处理阶段/级别实行不同的函数。例如，一个处理阶段/级别确定其输出声明性要求中的逻辑连接，另一个处理阶段/级别确定其输出声明性要求中的物理连接，并且另一个处理阶段/级别确定其输出声明性要求中的布线图（cabling diagram）。

在各种实施例中，可以存在任何数量的代理。每个代理可以实行可以由一个或多个相关联的触发模式触发的相同和/或不同的函数。在一些实施例中，代理协调并实行服务正在运行的验证。例如，已经接收到的期望网络/设备服务的期望配置被用来为所利用的一个或多个设备生成一个或多个设备验证模型。每个设备验证模型可以标识要针对验证模型的特定设备验证/检测的一个或多个参数。设备验证模型与提供给设备的设备要求不同，以实现用以配置设备的设备要求。例如，提供设备要求来配置/设置设备以提供服务，而提供设备验证模型来验证服务的状态和/或配置。在一些实施例中，响应于设备验证模型，从对应的设备接收状态报告，其标识在验证模型中标识的一个或多个参数的状态。然后，代理可以聚合和分析一个或多个状态报告，以确定服务是否已被正确实现/配置和/或是否正常运行。

由网络设备106执行的一个或多个处理代理接收网络设备106的设备要求，并且由网络设备108执行的一个或多个处理代理接收网络设备108的设备要求。这些代理中的每一个可以生成/实现/执行实现了设备要求的原生硬件指令以配置其相关联的个体网络设备。

在一些实施例中，由网络设备106托管的代理接收网络设备106的设备验证模型，并且由网络设备108托管的代理接收网络设备108的设备验证模型。这些代理中的每一个可以确定要报告的一个或多个状态参数以验证对应的设备验证模型，并且收集/检测所确定的状态参数。然后，每个代理可以向正在处理所正在提供服务的验证的另一个代理提供所收集/检测到的状态参数的状态报告。在一些实施例中，每个代理报告关于其相关联的（一个或多个）设备的状态、操作的信息和/或其他信息。然后，不同的代理可以收集并处理所报告的信息以报告该信息和/或实行响应动作。例如，当代理提供其相关联的设备过载的状态更新时，另一个代理（例如，由管理服务器102托管的）可以向网络添加新设备以卸载处理和/或将过载设备的处理任务移动到另一个网络设备。所收集的状态信息可以由代理提供为报告和/或动作的请求。

数据存储104存储图形模型的数据。数据存储104可以被包括在联网的存储服务中。在所示的示例中，代理经由网络110访问数据存储104。在一些实施例中，数据存储104经由非共享连接直接连接到管理服务器102。在各种实施例中，数据存储104被包括在图1中所示的任何组件中。例如，数据存储104被包括在服务器102中。数据存储104可以包括管理存储在数据存储104中的数据的服务器。数据存储104的示例包括数据库、高度可用的存储装置、分布式存储装置、云存储装置、数据服务或任何其他类型的数据存储装置。

网络设备106和网络设备108可以是连接到网络110的任何类型的设备。网络设备106和网络设备108的示例包括服务器、网络交换机、网络路由器、高速缓存服务器、存储设备、管理程序交换机、虚拟路由器、负载平衡器、防火墙、网络结构设备、虚拟网络设备、软件设备、软件组件或可以是物理或虚拟的任何类型的计算机或联网设备。所示代理是被包括在对应组件中的软件和/或硬件组件。网络110的示例包括下述各项中的一个或多个：直接或间接物理通信连接、移动通信网络、互联网、内联网、局域网、广域网、存储区域网络以及将两个或更多个***、组件或存储设备连接在一起的任何其他形式。其他通信路径可能存在，并且图1的示例已经被简化以清楚地图示示例。

虽然已经示出了图1中所示的许多组件的单个实例以简化示图，但是可以存在图1中所示的任何组件的附加实例。例如，可以存在任何数量的管理服务器、存储装置和网络设备。管理服务器102可以是服务器的集群，并且存储装置104可以是分布式存储装置。可以存在任何数量的代理。单个服务器/设备可以包括任何数量的代理。虽然图1中所示的示例示出了被包括/安装在它们各自相关联的***组件中的每个代理，但是代理可以被包括在不同的服务器/设备中。例如，可以将单个代理指派给跨多个网络设备的处理。也可以存在图1中未示出的组件。在一些实施例中，图1的每个资源（例如，每个代理、服务器和网络设备）可以属于域。例如，属于同一域的资源是可互操作的，并且可以一起起作用来实行网络配置和/或管理任务。在一些实施例中，每个资源可以仅属于一个域，并且保证仅同一域内的资源可互操作以实行网络配置和/或管理任务。某些资源可以属于多个域。可以利用多个域来管理单个网络。图1中所示的组件可以是一个或多个域的组件。图1中所示的任何组件可以是物理或虚拟的组件。

图2是图示了用于公布网络要求的过程的实施例的流程图。图2的过程可以在图1的管理服务器102上实现。

在202处，接收一组要求。在一些实施例中，该组要求包括标识了期望服务的意图的规范以及要被用来实现该意图的相关参考设计。参考设计可以标识组件***和设备要被组织成提供服务的标准方式。例如，参考设计标识要被用来提供意图的网络服务的网络拓扑结构和（一个或多个）协议。该意图可以指定期望服务的一个或多个要求（例如，声明性网络要求），而与要被利用的参考设计无关。例如，该意图可以指定将20个服务器联网在一起。意图是使用指定的参考设计并且通过改变参考设计的规范来实现，可以改变相同意图的实现方式来利用新指定的参考设计。通过分离意图和参考设计的规范，可以通过简单地指定不同的参考设计以及相同的意图来实现意图的不同参考设计实现方式。

在一些实施例中，该组要求包括网络/服务和/或连接到网络或能够连接到网络的一个或多个设备的期望配置、设置、拓扑结构和/或其他规范。在一些实施例中，该组要求包括一组声明性要求。例如，声明性要求表达网络组件的期望配置，而不指定确切的原生设备配置和控制流程。通过利用声明性要求，可以指定应当完成什么，而不是其应当如何完成。声明性要求可以与命令式指令形成对比，该命令式指令描述了用以实现配置的确切设备配置语法和控制流程。通过利用声明性要求而不是命令式指令，用户和/或用户***减轻了确定实现用户/***的期望结果所需的确切设备配置的负担。例如，当利用来自不同供应商的各种不同类型的设备时，指定和管理用以配置网络的每个设备的确切命令式指令通常是困难和繁重的。当添加新设备和设备故障发生时，网络的设备的类型和种类可能动态改变。利用不同的配置协议、语法和软件版本管理来自不同供应商的各种不同类型的设备以配置设备的内聚（cohesive）网络通常难以实现。因此，通过仅要求用户/***来指定规定了跨各种不同类型的设备适用的期望结果的声明性要求，网络设备的管理和配置变得更高效。

在各种实施例中，该组网络要求指定一个或多个设备的期望配置、期望动作、命令或任何其他指令或期望的结果。该组网络要求的一个示例是用以建立端点的连接网络的一组要求。例如，端点可以表示服务器、虚拟机、容器或应用程序。

例如，意图是将500个服务器连接在一起，并且参考架构是网状网络（例如，第3层Clos网络）。在Clos网络参考架构中，每个较低层次的交换机（例如，叶（leaf））以全网状拓扑结构连接到每个顶层次的交换机（例如，脊（spine））。指定用以建立经由所接收到的要求文件而接收到的L3 Clos网络配置的指令的示例意图的一部分如下：

网络架构=Clos/BGP

连接的服务器的#=144500

IP地址池=10.0.0.0/20

ASN池=[1000-1100]

上述要求指定应当建立具有500个网络服务器的网络，并且要建立的网络的网络架构拓扑结构是使用边界网关协议（BGP）的Clos网络，其中所需的IP地址从范围10.0.0.0到10.0.15.255分配，并且ASN（自治***号）从1000到1100的范围分配。

在一些实施例中，针对有效性和正确性验证该组要求。例如，验证了该组网络要求已从经授权和证实的源接收，所提供的要求规范语法是正确的，已经提供了有效要求，已经指定了针对期望结果的全部所需参数，并且所提供的要求能够经由可用的硬件/软件资源/设备来实现。

在一些实施例中，该组要求是一组声明性要求，其指定期望的配置、期望的动作、期望的映射结果、命令或一个或多个声明性要求处理阶段/级别的任何其他期望结果。在一些实施例中，可以为连续声明性要求处理阶段/级别的一个或多个所选处理阶段/级别指定该组要求。例如，存在多个处理连续阶段/级别，其在每个较低阶段/级别连续地需要更具体/更低阶段/级别声明性要求，并且用户可以指定任何一个阶段/级别的声明性要求。在一些实施例中，每个处理阶段/级别确定要配置的网络的附加方面。例如，每个处理阶段/级别的输出包括进一步定义所需网络的附加方面的附加声明性要求。

在一些实施例中，为所选处理阶段/级别指定该组声明性要求。例如，可以基于在自动设置由指定的声明性要求定义的网络时期望要控制的定制和细节的量，为最一般和最高处理阶段/级别或为较低和更具体的处理阶段/级别指定网络声明性要求。如果适用的话，每个处理阶段/级别可以将输入要求转换为输出要求，该输出要求可以被用作下一个处理阶段/级别的输入要求。例如，通过在多个处理阶段/级别中的每一个处以更多特异性连续地将声明性要求转换成较低阶段/级别声明性要求，确定要由每个特定设备的每个处理代理配置的每个特定设备的声明性要求。

在一些实施例中，不是要求用户来指定符合单一特异性水平的声明性要求，而是用户能够在对应于多个处理级别/阶段的多个不同特异性级别中的任何一个处指定声明性要求。因此，通过能够在多个不同的所选级别中的任何一个级别处提供期望的网络声明要求，可以给予用户选择以指定用户在配置网络时期望的控制的级别/量。例如，期望快速建立默认配置网络的网络管理员可以指定最高阶段/级别处的声明性要求（例如，要支持的服务器的数量），而期望设置更加定制和特定的网络的网络管理员可以指定较低阶段/级别处的声明性要求（例如，网络交换机之间的特定线缆连接映射）。

在一些实施例中，每个阶段使用一个或多个约束（例如，可用资源、要遵循的策略等）来处理输入要求以确定输出要求。在一些实施例中，在代理处接收约束。例如，用户提供用于存储在数据存储中以供在一个或多个处理阶段中使用的约束（例如，可用资源、要遵循的策略等）。在一些实施例中，如果用户尚未指定所需的声明性要求，则利用与指定的声明性要求一致的默认声明性要求。在一些实施例中，可以为多个不同的处理阶段/级别指定声明性要求。例如，用户可以为起始处理阶段/级别而且也为另一个较低处理阶段/级别指定高级声明性要求以定制期望的方面。在一些实施例中，以JavaScript对象表示法（即，JSON）格式指定声明性要求。

在204处，接收一个或多个约束。在一些实施例中，经由接口从用户接收一个或多个约束。例如，经由用户界面（例如，web界面、应用程序界面、命令行界面、应用程序编程接口（API）、RESTful API、配置文件界面等）接收约束（例如，可用资源、要遵循的策略等）。在一些实施例中，已经自动确定约束。例如，约束包括可用的网络交换机列表，并且已自动发现可用资源。在一些实施例中，约束包括标识资源的信息。例如，接收关于可以被利用来确定输出声明性要求的硬件和/或软件资源的标识信息。在一些实施例中，约束包括一个或多个策略的规范。例如，如何确定输出要求的策略规范由策略约束指定（例如，如何指派设备名称、如何指派端口映射等）。在一些实施例中，策略约束可以包括一个或多个规则、逻辑、程序代码和/或映射，其至少部分地指定如何从输入声明性要求确定输出。在一些实施例中，约束可以与代理的输入声明性要求一起使用，以确定多个处理阶段/级别的至少一个处理阶段/级别的输出要求。在一些实施例中，所接收到的约束与至少一个特定处理阶段/级别相关联。

在206处，利用所接收到的一组要求和所接收到的一个或多个约束来生成被利用来配置计算基础结构的图形表示。在一些实施例中，为计算基础结构设置操作状态预期并随后进行证实。在一些实施例中，利用所接收到的一组网络要求和所接收到的一个或多个约束来确定一组输出要求。例如，所接收到的一组输入要求和所接收到的一个或多个适用的约束被用来确定较低级别的输出声明性要求。在一些实施例中，所接收到的一组网络要求是一组声明性要求，其要使用一个或多个约束来处理，以最终确定要被配置成实现期望网络的一个或多个设备的一组声明性设备要求。在一些实施例中，经由处理代理实现一个或多个处理阶段/级别的进展以确定声明性要求的最终输出集合。在一些实施例中，利用一个或多个处理阶段/级别的定向图形进展来确定声明性要求的最终输出组。

在一个示例中，利用建立先前描述的建立L3 Clos网络的一组要求来生成意图的网络配置和操作状态的图形表示。与图形模型的每个节点相关联的数据的示例包括：标识符、节点类型（例如，服务器、交换机、接口、规则、策略等），描述性标记（例如，节点的描述）、标签、和其他属性（例如，一个或多个键值对）。与图形模型的每个边缘相关联的数据的示例包括：标识符、边缘类型（例如，托管接口、托管在其上等）、由边缘连接的源节点、由边缘连接的目标节点、描述性标记（例如，边缘的描述）、标签和其他属性（例如，一个或多个键值对）。

各种处理代理实行处理以创建、实现、验证和/或修改图形表示。每个代理与一个或多个触发图形表示模式相关联，这些触发图形表示模式将触发相关联的代理，并且当由于初始规范而创建或修改图形表示时和/或作为由修改图形表示的另一个代理进行处理的结果，确定改变是否影响任何触发模式。如果该改变影响触发模式，则将该改变通知给与受影响的触发模式相关联的处理代理。例如，处理代理利用一组具有相关联的回调的一个或多个规则以声明方式授权。每个代理的回调函数和业务逻辑函数可以实行生成配置和部署计算基础结构所需的处理的部分。例如，各种代理的回调函数实行语义证实、收集遥测和执行数据、和/或在执行期间检测异常。

在一些实施例中，代理一起实际上分析所接收到的要求，并且确定和标识将被利用来实现所接收到的网络要求的期望网络配置的设备。示例性L3 Clos网络要求指定脊网络交换机设备的数量为6，并且指定叶网络交换机设备的数量为32。总计，代理将确定并标识将需要被配置成实现期望的Clos网络的38个设备。对于要利用的每个设备，代理在实现期望的Clos网络时确定个体设备要求。对于L3 Clos网络示例，以下是针对38个不同设备要求中的一个的设备要求的一个示例。

角色 = 脊

IP地址 = 10.0.0.3

ASN = 1000

邻居 = [(叶-1, 10.0.0.7, 1010), (叶-2, 10.0.0.15, 1011),… (叶-32,  10.0.0.176), 1042]

状态 = 已定义

上述设备要求在Clos网络中指定一个网络交换机设备是具有被定义为IP地址10.0.0.3和ASN 1000的BGP路由器标识符的脊交换机。还已标识了连接到该脊交换机设备的叶交换机，以及它们的IP和ASN。

在一些实施例中，206中实行的处理包括实行多个连续声明性要求处理阶段/级别的一个或多个处理阶段/级别的处理。例如，使用一个或多个代理来实行一个处理阶段/级别的处理，并且该处理级别的输出声明性要求被用来向图形表示添加/修改数据，这可能触发实际上用作下一个处理阶段的输入声明要求的其他代理的其他触发模式，如果适用的话。在一些实施例中，如果没有为特定处理阶段/级别指定声明性要求，则可以基于所接收到的声明性要求（例如，为了一致）自动确定处理阶段/级别的所需输入声明性要求，和/或利用处理阶段/级别的默认声明性要求。

在一些实施例中，利用一个或多个约束包括利用标识资源的信息来向硬件/软件资源指派配置/从硬件/软件资源指派配置。例如，要从设备资源列表中选择要被配置的设备。在另一个示例中，从可用配置参数范围的列表中选择配置参数。在一些实施例中，利用约束包括利用一个或多个策略的规范。例如，如何根据输入要求确定输出要求的策略规范由策略指定（例如，如何指派设备名称、如何指派端口映射等）。在一些实施例中，策略包括一个或多个规则、逻辑、程序代码和/或映射，其至少部分地指定如何从输入声明性要求确定输出声明性要求。

在一些实施例中，被利用来确定输出要求的代理是可配置/可定制的。例如，用户可以修改、扩展和/或配置由代理实行的触发模式和/或回调函数处理。代理可以是可经由诸如API之类的接口来配置/定制的。

在一些实施例中，验证一组输出要求。在一些实施例中，验证该组输出要求包括实行一个或多个测试以确定该组输出要求是否有效并且与（一个或多个）输入要求的意图相匹配。在一些实施例中，要实行的测试可以取决于该组输出要求的处理阶段/级别、输入要求的内容、输出要求的内容、所利用的代理、所利用的一个或多个约束、和/或被实行以确定输出声明性要求的处理。在一些实施例中，验证图形表示以确保其符合定义了图形表示的允许元素以及如何允许图形表示被构造/连接的大纲。例如，由新的/修改的元素或图形表示的连接触发的代理经由其回调函数来执行新的/修改的元素或连接的验证，以确保它满足大纲的规则。

图3A是图示了用于使用所接收到的声明性要求自动配置网络的示例过程的实施例的流程图。图3A的过程可以实现在图1的管理服务器102上。在一些实施例中，图3A的过程由一个或多个不同的代理至少部分地实行。例如，每个处理阶段/级别可以由一个或多个代理执行。在一些实施例中，在图2的206中包括图3A的过程的至少一部分。在一些实施例中，利用图3A的过程来自动配置L3 Clos网络。例如，利用图3A的过程来为特定网络域和网络递送点（即，PoD）配置L3 Clos网络。

在一些实施例中，取决于用户提供的输入声明性要求的级别，可以在过程的任何步骤处灵活地启动/输入图3A的过程。在一些实施例中，在接收到用以配置网络的声明性要求（例如，在图2的202处接收）之后，确定与所接收到的声明性要求相对应的声明性要求处理阶段/级别的处理阶段/级别。例如，分析所接收到的声明性要求以确定在所接收到的声明性要求中指定的要求的级别/类型，并且标识与所接收到的声明性要求相对应的多个处理阶段/级别的处理阶段/级别。在一些实施例中，确定图3A的过程的哪个步骤（例如，步骤310至320中的哪一个）对应于所标识的处理阶段/级别，并且在所确定的步骤处进入/开始图3A的过程。

在310处，实行逻辑连接处理阶段/级别的处理以确定定义逻辑连接的输出。在一些实施例中，在多个声明性要求处理阶段/级别的处理阶段/级别处确定逻辑连接。在一些实施例中，处理逻辑连接处理阶段/级别包括使用输入声明性要求来确定输出声明性要求。在一些实施例中，在图2的202中至少部分地接收输入声明性要求。在一些实施例中，处理逻辑连接处理阶段/级别包括确定标识叶网络交换机与脊网络交换机之间的逻辑连接的输出声明性要求，以实现定义期望的L3 Clos网络的输入声明性要求。该处理阶段/级别的输入声明性要求可以指定以下各项中的一个或多个：使用要建立的L3 Clos网络连接的服务器的数量；以及超额订阅比率（例如，理论上网络交换机端口可能需要的最大带宽量对比网络交换机端口的实际最大带宽容量）。在一些实施例中，获得（例如，在图2的204中获得）并且利用（例如，在图2的206中利用）约束来确定输出声明性要求。例如，获得可用来被利用以（例如，在没有标识特定的确切机器的情况下）创建L3 Clos网络的设备（例如，网络硬件交换机）的简档（例如，面向交换机的端口的数量、面向服务器的端口的数量等），并且在选择要在标识网状网络的输出声明性要求中使用的设备类型时利用该设备的简档。在一些实施例中，仅在约束中标识的设备可以是在输出声明性要求中标识的交换机。

在一些实施例中，逻辑连接处理阶段/级别的输入声明性要求包括由用户提供的一个或多个声明性要求。例如，逻辑连接处理阶段/级别的输入声明性要求包括在图2的202中接收到的声明性要求。在一些实施例中，输入声明性要求的至少一部分尚未由用户直接指定，并且利用默认和/或动态确定的声明性输入要求。可以确定动态确定的声明性输入要求以至少部分地与用户提供的输入声明性要求一致。在一些实施例中，如果用户提供输入声明性要求的较低/较晚级别/阶段，则不实行步骤310。例如，在312处输入图3A的过程。在一些实施例中，验证输出声明性要求以确保满足了性能预期和/或输入声明性要求的意图。在一些实施例中，验证输出声明性要求以验证所利用的网络交换机的数量和/或类型，和/或在输出声明性要求中利用的设备。

在312处，实行物理连接处理阶段/级别的处理以确定定义物理连接的输出。在一些实施例中，从逻辑连接到物理连接的变换涉及将交换机模型指派给逻辑设备，并且实行证实以确保所选交换机模型具有参与网络配置中的必要先决条件（诸如，具有特定线路速率的端口的数量）。在一些实施例中，物理连接处理阶段/级别是多个声明性要求处理阶段/级别之一。在一些实施例中，处理物理连接处理阶段/级别包括使用输入声明性要求来确定输出声明性要求。该处理阶段/级别的输入声明性要求可以是310的处理阶段/级别的输出声明性要求。在一些实施例中，在图2的202中至少部分地接收到输入声明性要求。在一些实施例中，处理物理连接处理阶段/级别包括确定输出声明性要求，该输出声明性要求标识与输入声明性要求中指定的逻辑连接相对应的特定设备类型之间的物理连接。在一些实施例中，获得（例如，在图2的204中获得）并且利用（例如，在图2的206中利用）约束来确定输出声明性要求。例如，获得可用来被利用以创建L3 Clos网络的特定设备类型的简档（例如，网络硬件交换机的特定模型/供应商），并且在选择要在标识L3 Clos网状网络的输出声明性要求中利用的特定设备类型时利用该特定设备类型的简档。在一些实施例中，将特定设备类型指派给输入声明性要求的逻辑设备，以确定该处理阶段的输出声明性要求。

在一些实施例中，物理连接处理阶段/级别的输入声明性要求包括由用户提供的一个或多个声明性要求。例如，物理连接处理阶段/级别的输入声明性要求包括在图2的202中接收到的声明性要求。在一些实施例中，输入声明性要求的至少一部分尚未由用户直接指定，并且利用默认和/或动态确定的声明性输入要求。可以确定动态确定的声明性输入要求以至少部分地与用户提供的输入声明性要求一致。在一些实施例中，如果用户提供比物理连接处理阶段/级别的级别更低/更晚级别/阶段的输入声明性要求，则不实行步骤312。例如，在314处输入图3A的过程。在一些实施例中，验证输出声明性要求以确保正确的路由表与输入声明性要求一致。在一些实施例中，验证输出声明性要求以验证被包括在输出声明性要求中的路由表和/或特定设备类型。

在314处，实行布线图处理阶段/级别的处理以确定定义布线图/映射的输出。在一些实施例中，布线图处理阶段/级别是多个声明性要求处理阶段/级别之一。在一些实施例中，处理布线图处理阶段/级别包括使用输入声明性要求来确定输出声明性要求。该处理阶段/级别的输入声明性要求可以是312的处理阶段/级别的输出声明性要求。在一些实施例中，输入声明性要求在图2的202中至少部分地接收。在一些实施例中，处理布线图处理阶段/级别包括确定输出声明性要求，该输出声明性要求标识定义了在输入声明性要求中指定的L3 Clos交换机的端口之间的连接的布线图/映射。在一些实施例中，获得（例如，在图2的204中获得）并且利用（例如，在图2的206中利用）约束来确定输出声明性要求。例如，获得用来被利用以创建L3 Clos网络的特定设备（例如，网络硬件交换机）的端口映射/标识和端口资源的约束，并且在确定L3 Clos网状网络的交换机的端口之间的特定线缆连接时利用该约束。在一些实施例中，在确定该处理阶段的输出声明性要求时，为特定端口指派各种角色（例如，面向服务器、脊、边缘等）。在一些实施例中，在确定布线图输出声明性要求时利用一个或多个策略/规则/代码约束。

在一些实施例中，布线图处理阶段/级别的输入声明性要求包括由用户提供的一个或多个声明性要求。例如，布线图级别的输入声明性要求包括在图2的202中接收到的声明性要求。在一些实施例中，输入声明性要求的至少一部分尚未由用户直接指定，并且利用默认和/或动态确定的声明性输入要求。可以确定动态确定的声明性输入要求以至少部分地与用户提供的输入声明性要求一致。在一些实施例中，如果用户提供比布线图处理阶段/级别的级别更低/更晚级别/阶段的输入声明性要求，则不实行步骤314。例如，在316处输入图3A的过程。在一些实施例中，验证输出声明性要求以确保正确的布线和/或端口（例如，端口函数）映射。

在316处，实行候选要求处理阶段/级别的处理以确定定义软资源指派的输出。在一些实施例中，候选要求处理阶段/级别是多个声明性要求处理阶段/级别之一。在一些实施例中，处理候选要求处理阶段/级别包括使用输入声明性要求来确定输出声明性要求。该处理阶段/级别的输入声明性要求可以是314的处理阶段/级别的输出声明性要求。在一些实施例中，在图2的202中至少部分地接收输入声明性要求。在一些实施例中，处理候选要求处理阶段/级别包括确定输出声明性要求，该输出声明性要求标识在输入声明性要求中标识的连接的指派软资源。在一些实施例中，获得（例如，在图2的204中获得）并且利用（例如，在图2的206中利用）约束来确定输出声明性要求。例如，包括可用来被指派的软资源的列表（例如，IP地址范围、自治***号（ASN）范围等）的约束在将软资源指派给网络交换机连接时被利用。在一些实施例中，在指派输出声明性要求中指定的软资源时利用一个或多个策略/规则/代码约束。

在一些实施例中，候选要求处理阶段/级别的输入声明性要求包括由用户提供的一个或多个声明性要求。例如，候选要求级别的输入声明性要求包括在图2的202中接收到的声明性要求。在一些实施例中，输入声明性要求的至少一部分尚未由用户直接指定，并且利用默认和/或动态确定的声明性输入要求。可以确定动态确定的声明性输入要求以至少部分地与用户提供的输入声明性要求一致。在一些实施例中，如果用户提供比候选要求处理阶段/级别的级别更低/更晚级别/阶段的输入声明性要求，则不实行步骤316。例如，在318处输入图3A的过程。在一些实施例中，验证输出声明性要求以确保正确的IP指派、ASN、边界网关协议（BGP）会话等。尽管已经描述了ASN示例，但是在各种实施例中可以利用其他参考架构和路由协议。例如，可以利用不需要ASN的不同路由协议，诸如开放最短路径优先（OSPF）。

在318处，实行呈现的要求处理阶段/级别的处理以确定定义任何扩展/可选要求的输出。在一些实施例中，所呈现的要求处理阶段/级别是多个声明性要求处理阶段/级别之一。在一些实施例中，处理所呈现的要求处理阶段/级别包括使用输入声明性要求来确定输出声明性要求。该处理阶段/级别的输入声明性要求可以是316的处理阶段/级别的输出声明性要求。在一些实施例中，输入声明性要求在图2的202中至少部分地接收。在一些实施例中，处理所呈现的要求处理阶段/级别包括确定标识最终配置的输出声明性要求，该最终配置包括要建立的L3 Clos网络的任何扩展/可选要求/配置。在一些实施例中，获得（例如，在图2的204中获得）并且利用（例如，在图2的206中利用）约束来确定输出声明性要求。例如，在确定在输出声明性要求中指定的最终要求的扩展/可选要求/配置时，利用要为特定类型的设备分配的扩展/可选配置的规范（例如，要从候选配置、参数等添加/替代的配置）。在一些实施例中，在确定所呈现的要求输出声明性要求时利用一个或多个策略/规则/代码约束。

在一些实施例中，所呈现的要求处理阶段/级别的输入声明性要求包括由用户提供的一个或多个声明性要求。例如，所呈现的要求级别的输入声明性要求包括在图2的202中接收到的声明性要求。在一些实施例中，输入声明性要求的至少一部分尚未由用户直接指定，并且利用默认和/或动态确定的声明性输入要求。可以确定动态确定的声明性输入要求以至少部分地与用户提供的输入声明性要求一致。在一些实施例中，如果用户提供比所呈现的要求处理阶段/级别的级别更低/更晚级别/阶段的输入声明性要求，则不实行步骤318。例如，在320处输入图3A的过程。在一些实施例中，验证输出声明性要求以确保正确的最终配置。

在一些实施例中，为所呈现的要求处理阶段/级别实行处理包括为要被配置成提供期望服务的***（例如，设备）的每个组件标识和调用用以生成针对***的组件的所呈现的要求的函数。在一些实施例中，存在多个不同的函数，每个函数特定于特定参考架构和该参考架构内的***组件角色。例如，对于要被利用来提供意图的网络服务的每个***组件，配置***组件的所呈现的要求由特定于参考架构和***组件的角色的特定程序函数生成。在一些实施例中，为了支持新的参考架构，要提供针对参考架构内的每个可能角色（例如，设备类型）的单独函数，使得可以定位和调用该函数以在需要时实现该参考架构。

在320处，实行经证实的要求处理阶段/级别的处理以确定包括特定设备要求的输出。在一些实施例中，经证实的要求处理阶段/级别是多个声明性要求处理阶段/级别的最终处理阶段/级别。在一些实施例中，处理经证实的要求处理阶段/级别包括使用输入声明性要求来确定输出声明性要求。该处理阶段/级别的输入声明性要求可以是318的处理阶段/级别的输出声明性要求。在一些实施例中，输入声明性要求在图2的202中至少部分地接收。在一些实施例中，处理经证实的要求处理阶段/级别包括确定输出声明性要求，其将最终配置指派给要被配置成实现L3 Clos网络的特定网络设备。在一些实施例中，获得（例如，在图2的204中获得），并且利用（例如，在图2的206中利用）约束来确定输出声明性要求。例如，接收包括特定设备简档的规范、特定实际设备的可用性和/或特定设备的唯一标识符（例如，序列号）的约束，以确定要在输出声明性要求中指定的特定设备/交换机指派。在一些实施例中，在指派经证实的要求输出声明性要求中指派的特定设备时利用一个或多个策略/规则/代码约束。

在一些实施例中，经证实的要求处理阶段/级别的输入声明性要求包括由用户提供的一个或多个声明性要求。例如，所呈现的要求级别的输入声明性要求包括在图2的202中接收到的声明性要求。在一些实施例中，输入声明性要求的至少一部分尚未由用户直接指定，并且利用默认和/或动态确定的声明性输入要求。可以确定动态确定的声明性输入要求以至少部分地与用户提供的输入声明性要求一致。在一些实施例中，如果用户提供了标识特定设备的最终证实的要求，则不实行步骤320。在一些实施例中，验证输出声明性要求以确保正确的特定设备指派。在一些实施例中，输出声明性要求要被推送到特定代理以配置特定设备/交换机。例如，在图4的402处接收该阶段/级别的输出声明性要求。

在一些实施例中，318和/或320中的处理包括为要被配置成提供期望服务的每个***组件（例如，节点、设备等）标识和调用配置/服务呈现程序函数以为组件生成呈现/输出的要求。在一些实施例中，存在多个不同的函数，每个函数特定于参考架构内的特定参考架构和***组件角色。例如，对于要被利用以提供意图的网络服务的每个***组件，配置***组件的呈现/输出要求由特定于参考架构和***组件角色的特定程序函数生成。在一些实施例中，为了支持新的参考架构，要提供针对参考架构内的每个可能角色（例如，设备类型）的单独函数，使得可以定位和调用该函数以在需要时实现该参考架构。

在一些实施例中，318和/或320中的处理包括为要被配置成提供期望服务的***的每个组件（例如，节点、设备等）标识和调用验证模型呈现函数来为***的组件生成验证模型。在一些实施例中，存在多个不同的函数，每个函数特定于特定参考架构和参考架构内的***组件角色，以生成对应的验证模型。例如，对于要被利用提供意图的网络服务的每个***组件，验证模型由特定程序函数生成（例如，验证模型呈现函数不同于服务呈现函数，其生成对于***组件的呈现/输出要求），该特定程序函数特定于参考架构和***组件的角色。验证模型可以由一个或多个代理利用以实行相关联的图形表示的节点/组件和/或元素的验证。

尽管已经在图3A的示例中示出了处理阶段/级别的简单线性进展以简化示例，但是各种处理代理可以使用可以至少部分并行的各种处理次序和路径来实行图3A中所示的工作流程。

图3B是图示了用于自动配置L3 Clos网络的示例过程的处理阶段/级别的框图。图3B中所示的处理可以在图1的管理服务器102上实现。在一些实施例中，图3B中所示的处理由一个或多个不同的处理代理至少部分地执行，该处理代理由相关联的图形表示的至少一部分（例如，匹配代理的触发模式的图形表示部分）触发。在一些实施例中，图3B中所示的处理被包括在图2的206中。在一些实施例中，图3B图示了图3A的过程。在一些实施例中，用户能够在连续处理阶段/级别中的任何一个处灵活地进入图3B中所示的处理，这取决于用户提供的输入声明性要求的级别。如示图330所示，先前/更高级别阶段的输出被下一个较低级别的一个或多个代理用作其输入声明性要求。例如，先前级别代理的输出更新图形表示的一部分，并且该更新触发了下一级别代理的模式。代理可以利用先前代理的输出以及预定义的输入约束来确定输出以更新图形表示。

图4是图示了用于生成原生硬件指令的过程的实施例的流程图。图4的过程可以在图1的网络设备106和/或108上实现。在一些实施例中，图4的过程由图1的网络设备106和/或108的一个或多个处理代理实行。

在402处，在代理处接收设备要求。在一些实施例中，代理是由图1的网络设备106和/或108执行的代理。在一些实施例中，代理是管理和实现针对相关联/指派的设备的设备要求的软件和/或硬件组件。在一些实施例中，针对不同的网络设备存在不同类型/版本的代理。例如，代理提供设备要求和实现特定于设备的原生指令之间的转换功能，并且针对特定设备选择可以生成用于特定设备（例如，特定于设备的供应商、操作***、协议、版本等）的原生指令的代理。因为代理需要处理设备的特定原生指令，因此当将新的类型或版本的设备添加到网络时，只需要用于新设备的新的代理，而实行其他函数的代理可以保持不变。例如，促进与用户的交互以接收和提供期望要求、规范和状态更新的交互代理，或实现和管理跨各种网络设备的期望网络要求、配置和状态更新的应用代理不需要改变。这可以允许网络的各种不同类型的设备的简化管理。代理可以被安装在由代理管理的设备上。在一些实施例中，代理远离被管理设备。在一些实施例中，一个代理可以管理多个设备。例如，单个代理可以管理相同类型的多个设备。在一些实施例中，设备特定指令在服务器处生成，并且被提供给代理，该代理负责在设备上应用所提供的指令并且报告应用所提供的指令的状态。

在一些实施例中，所接收到的设备要求是在图2的206中针对设备生成的图形表示中指定的设备要求。在一些实施例中，每个不同的代理与图形模型的触发模式相关联，该触发模式标识与对应的代理相关联的设备。在一些实施例中，接收设备要求包括由于订阅来接收设备要求已被存储到数据存储的指示，并且代理从数据存储请求和获得设备要求。在一些实施例中，接收设备要求包括由于订阅自动从数据存储接收设备要求的内容。在一些实施例中，接收设备要求包括直接从代理接收设备要求。

在404处，使用代理来生成原生硬件指令以配置代理的设备。在一些实施例中，在软件库中生成原生硬件指令，并且由代理利用所生成的原生硬件指令。在一些实施例中，由代理处理由代理接收到的设备要求以生成实现所接收到的设备要求的原生硬件指令。例如，所接收到的声明性指令被转换成命令式指令。在一些实施例中，原生硬件指令采用设备的原生编程/配置语法。例如，以对于设备的配置软件接口原生的格式生成原生硬件指令。在一些实施例中，原生硬件指令采用可以由设备直接利用以配置设备的形式。在一些实施例中，原生硬件指令由设备执行。例如，所生成的原生硬件指令被发布以用于在设备上执行。

在一个示例中，在代理处接收成为先前在说明书中描述的L3 Clos网络配置的脊交换机的设备要求，并且代理分析所接收到的设备要求，并生成原生网络交换机设备指令以将网络交换机设备配置为成为具有指定BGP路由器标识符和指定邻居的Clos网络的脊交换机。

在406处，提供设备的状态。在一些实施例中，步骤406是可选的，并且可以不实行。在一些实施例中，提供状态包括更新图形表示中对应的节点中的数据、状态的标识符。在一些实施例中，提供状态包括提供实现所接收到的设备要求的状态的指示。例如，提供了设备要求的处理的阶段的状态指示。

在一些实施例中，设备的状态指示在设备上实现设备要求的状态。例如，状态可能是六种状态之一。初始的第一个示例状态是“已定义”状态，其指示已成功更新设备要求。第二示例状态是“暂存”状态，其指示已经分配资源以实现设备要求。第三示例状态是“呈现”状态，其指示已经生成了与设备要求相对应的原生硬件指令。第四示例状态是“部署”状态，其指示生成的原生硬件指令以在设备上执行。第五示例状态是“操作”状态，其指示在设备上成功执行生成的原生硬件指令。然而，当遇到错误时，可以指示第六示例“错误”状态以指示已经遇到错误。

在一些实施例中，设备的状态指示设备的健康状态。例如，可以提供诸如处理负载、CPU利用率、存储装置利用率、存储器利用率、版本标识、遇到的错误、网络状态、网络带宽、网络延迟等的信息的指示。在一些实施例中，设备的状态指示丢包率。例如，由代理提供设备的三进制内容可寻址存储器（即，TCAM）利用率的指示。在另一示例中，当TCAM表溢出时提供指示。

图5是图示了用于生成验证模型的过程的实施例的流程图。图5的过程可以在图1的管理服务器102上实现。

在502，接收服务的一组要求。在一些实施例中，所接收到的该组要求是在图2的202中接收到的那组网络要求。该服务可以是网络服务和/或其他类型的服务。在一些实施例中，该组要求包括一组声明性要求。例如，声明性要求表达网络组件的期望配置，而不指定确切的原生设备配置和控制流程。通过利用声明性要求，可以指定应当实现什么，而不是其应当如何实现。

在504，为该组要求的每个设备生成验证模型，以验证服务的状态和实现方式。在一些实施例中，生成验证模型包括使用所接收到的一组要求以及与该组要求相关联的一个或多个所接收到的约束来确定要被利用来生成一个或多个验证模型以及一个或多个设备配置的更完整的一组要求。例如，利用图3A的步骤316的输出来为一个或多个设备生成一个或多个验证模型，以被利用来实现要验证的服务。在该示例中，步骤316的输出被利用来生成要被利用来配置设备以提供服务的特定设备要求（例如，被利用来生成图3A的步骤318/320的输出）以及针对每个设备的以验证每个设备是否正常运行并且已经针对该组要求进行了正确配置的单独的验证模型两者。在一些实施例中，执行证实测试程序并且将结果与生成的预期进行比较。在一些实施例中，已经处理了所接收到的一组要求以包括诸如使用图3A的过程的至少一部分的布线图/映射之类的信息。例如，已经处理502中接收到的一组要求以指定网络组件之间的连接的拓扑结构。

在506，将每个生成的验证模型提供给被利用来实现期望服务的一个或多个设备的每个相应设备。在一些实施例中，提供所生成的验证模型包括将所生成的验证模型发送到相应设备的代理。例如，管理服务器102的代理将生成的验证模型发送到网络设备106的代理，并且发送另一个生成的验证模型以代理（proxy）图1的网络设备108的代理（agent）。在一些实施例中，提供每个生成的验证模型包括将每个生成的验证模型存储在被存储在数据存储（例如，图1的数据存储104）中的图形表示的节点的数据中，以允许一个或多个代理读取和访问其各自的来自图形表示的节点的验证模型。因此，不是将验证模型直接传送到设备，而是代理将验证模型存储到图形表示的节点以传送信息。

图6是图示了用于检测状态参数的过程的实施例的流程图。图6的过程可以在图1的网络设备106和/或108上实现。例如，图6的过程的至少一部分由网络设备106和/或网络设备108的一个或多个代理实行。

在602，接收验证模型。在一些实施例中，代理接收验证模型。代理可以是被配置成使用验证模型来处理验证的代理。该代理可以与图4中用以配置设备的代理相同或不同。在一些实施例中，接收到的验证模型是图5的506中提供的验证模型。例如，被验证设备的代理从另一个代理获得验证模型。

在一些实施例中，所接收到的验证模型是在图5的506中提供的针对代理的设备的验证模型。在一些实施例中，接收验证模型包括检测（例如，经由匹配的触发模式）验证模型已经存储在图形表示的节点中。在一些实施例中，验证模型包括连接中的一个或多个连接和相关参数的列表，并且验证模型的相关联的设备/代理要报告/验证所列连接的存在、状态和/或参数。

在一些实施例中，验证模型包括应当在验证模型的相关联的设备上操作的一个或多个服务过程的列表，并且相关联的设备/代理要报告/验证所列服务过程的存在、状态和/或参数。在一些实施例中，验证模型包括应当被配置并且在验证模型的相关联的设备上操作的一个或多个IP地址的列表，并且相关联的设备/代理要报告/验证所列IP地址存在、状态和/或参数。在一些实施例中，验证模型包括应当被验证的相关联的设备的一个或多个接口的列表，并且相关联的设备/代理要报告/验证所列接口的存在、状态和/或参数。在一些实施例中，验证模型包括相关联的设备的接口与应该被配置和操作的另一个连接设备之间的一个或多个连接的列表，并且相关联的设备/代理要报告/验证所列接口连接的存在、状态和/或参数。在一些实施例中，验证模型包括相关联的设备的一个或多个设备标识的列表，并且相关联的设备/代理要报告/验证所列设备标识的存在、状态和/或参数。

在604，确定要报告以验证验证模型的一个或多个参数。在一些实施例中，验证模型标识一个或多个参数。例如，验证模型包括感兴趣的参数的列表以及要报告的这些参数中的每一个的状态/验证。参数和状态的示例包括下述各项的参数/状态：连接会话、服务、IP地址、接口、接口连接、设备配置、设备属性、端口、服务质量度量等。在一些实施例中，验证模型标识要验证的更高概念项而不是要验证的特定参数，并且标识需要被验证以验证该项的一个或多个参数。例如，验证模型标识要验证的连接，并且标识需要验证的连接的一个或多个参数。在一些实施例中，确定一个或多个参数包括基于验证模型生成需要从设备检测的状态参数的列表。在一些实施例中，确定一个或多个参数包括标识要被验证以验证验证模型的项的设备/操作***特定参数。例如，验证模型包括不特定于特定设备类型和/或设备操作***的验证指令/参数，并且代理将验证指令转换为设备类型/操作***特定指令/参数。通过允许验证模型的协议/格式/指令是特定供应商/操作***不可知的，验证模型的生成被简化。因为每个代理可以特定于特定类型的设备供应商/操作***，所以代理是实行验证模型的通用验证项与特定于设备的特定项之间的转换的最有效实体。

在606处，检测所确定的参数。在一些实施例中，在接收到验证模型时实行参数检测。例如，实行初始验证以确保已在图形表示中正确初始化/配置的验证模型的服务。在一些实施例中，周期性地实行参数检测。例如，在持续的基础上以周期性间隔实行验证以确保服务的连续正常运行。在一些实施例中，周期性地（例如，每个周期性间隔）实行参数检测。在一些实施例中，动态地实行参数检测。例如，当检测到潜在的材料改变时（例如，在图形表示中），调用并实行参数检测以确保尽管有改变，服务仍然正常运行。改变的示例可以包括对以下各项中的一个或多个的改变：网络连接、设备硬件、设备操作***、设备的应用、错误事件以及与验证模型相关联的设备的任何状态。在另一示例中，当向设备（例如，交换机）操作***通知关于改变（例如，路由/路由表的改变）时，操作***通知代理作为响应触发参数检测。

在一些实施例中，检测所确定的参数包括获得参数的状态。例如，获得网络连接的状态。在另一示例中，确定所标识的过程是否仍在运行。在一些实施例中，检测所确定的参数包括获得参数的值。例如，确定所标识的网络连接的网络标识符（例如，IP地址）。在一些实施例中，检测所确定的参数包括获得从另一个设备向设备报告的信息。例如，实行验证检测的设备从其邻居设备接收状态报告/消息，并且获得被包括在这些报告/消息中的信息。在一些实施例中，检测所确定的参数包括对连接到实行验证检测的设备的另一设备实行查询。例如，查询消息被发送到另一个设备以检测参数。在另一示例中，可以发送ping消息或信息请求。在一些实施例中，检测所确定的参数包括从连接的节点/设备获得标识参数/状态的接收消息。例如，从对等交换机接收链路层发现协议（LLDP）消息，并且报告/分析该消息以实行验证。

在608，报告检测到的参数。例如，一个或多个检测到的参数由一个或多个代理（例如，管理服务器102的代理，其具有实行验证的任务）检测并且被存储在图形表示的一个或多个节点中。在一些实施例中，报告检测到的参数包括实行分析以确定验证结果。例如，由代理检测一个或多个检测到的参数，该代理由图形模型的节点的参数的改变触发，并且代理的回调函数实行与参数的一个或多个预期值的比较以确定是否已检测到预期值，并且报告中包括比较的结果的标识。在一些实施例中，报告检测到的参数包括使用由相关联的触发模式触发的代理的回调函数来确定一个或多个检测到的参数的概要。例如，对检测到的参数进行分类、组织、分析、计算和/或统计分析，并且在提供的报告中包括一个或多个结果。

在一些实施例中，报告检测到的参数包括将报告存储在图形表示的一个或多个节点中和/或将报告提供给用户。在一些实施例中，该报告包括一个或多个参数的确定的聚合概要/计数。例如，除了每个接口的个体状态/参数（例如，状态标识符、状态上次更新时间等）的列表之外，还确定活动、非活动、预期等的接口的数量，并将其包括在报告中。在另一示例中，除了每个会话的个体状态/参数（例如，会话状态、状态上次更新时间、源/目标IP地址/ASN等）的列表之外，还确定活动、不活动、预期等的会话（例如，BGP会话）的数量，并将其包括在报告中。在一些实施例中，报告包括LLDP消息的标识以及已经在设备与其对等设备之间交换的消息的一个或多个参数（例如，发送/接收接口和设备的标识、消息时间戳等）。

图7是图示了用于分析验证报告的过程的实施例的流程图。图7的过程可以在图1的管理服务器102上实现。在一些实施例中，图7的过程的至少一个或多个部分由一个或多个代理实行。

在702，接收一个或多个验证模型的检测到的参数的一个或多个报告。在一些实施例中，接收到的报告是在一个或多个实例处从一个或多个不同代理在608中提供的报告。例如，从已经被配置成提供正被验证的服务的每个设备接收报告。在一些实施例中，接收报告包括直接从一个或多个设备接收报告。在一些实施例中，接收报告包括从图形表示的一个或多个节点获得/接收报告。

在704处，对报告进行分析。例如，对接收到的报告中包括的报告数据进行关联、比较以及以其他方式分析，以确定服务是否已被正确实现/配置和/或是否正常运行。在一些实施例中，对应于服务的正常运行状态的一个或多个预期值和/或预期状态是已知的，并且对报告进行分析以验证已检测到预期值/状态。在一些实施例中，分析报告包括确定报告中是否已报告错误消息和/或意外状态的指示。

在一些实施例中，验证与接收到的状态相关联的预期。例如，实行一个或多个规则或测试来验证报告中包括的值是否如预期、指定的那样和/或在某一范围内。在一些实施例中，预期包括要被实行的一个或多个测试以验证已成功实现一组要求。例如，在图2的202中的接收到的一组网络要求指定了要被实行以验证已经成功实现了该组网络要求的一个或多个测试。例如，在贯穿说明书讨论的L3 Clos网络示例中，验证路由表已成功更新的测试和叶交换机节点知晓邻居反映接收到Clos网络配置以及图2的202中所接收到的网络要求。该测试可以由一个或多个代理连同图2的204中的要求一起公布，并且一个或多个代理接收该测试作为验证的预期。在一些实施例中，该预期标识了用于资源利用率指示符的可接受范围。在一些实施例中，该预期标识了所接收到的状态的错误状态。

在一些实施例中，实行分析包括确定满足吞吐量和/或服务质量/性能度量。在一些实施例中，实行行分析包括确定是否已经在来自提供服务的设备的全部报告中正确地配置/检测到提供期望服务的设备之间的全部所需连接。例如，不是仅仅隔离地检查每个报告，而是将来自不同设备的多个报告中报告的数据相关联，以确定被支持以连接的两个设备之间的连接数据/参数相匹配以创建有效连接。在一些实施例中，实行分析包括确定是否存在无关（或不应当存在以提供期望服务）的一个或多个参数/连接。在一些实施例中，实行分析包括验证域的隔离和/或确保一个域不过度利用资源。

在706，如果适用的话，基于报告的分析来实行动作。在一些实施例中，如果所接收到的报告中包括的数据如预期、指定的那样和/或在某一范围内，则不实行动作。例如，确定服务正常运行和/或已经被正确配置。在一些实施例中，确定服务未正常运行和/或未被正确配置，并且提供消息来指示该错误（例如，经由代理）。在一些实施例中，预期基于所接收到的报告的数据来标识要实行的响应动作。在一些实施例中，实行动作包括报告该报告的数据。例如，报告测试的结果（例如，报告测试的结果以验证已成功实现该组网络要求）。在一些实施例中，报告该报告的数据包括总结报告的数据。报告该报告的数据可以包括向代理提供报告/状态（例如，代理可以向用户提供报告/状态）。

在一些实施例中，实行动作包括配置、移动、移除和/或添加网络的设备和/或网络的设备的过程/程序。例如，代理生成指令（例如，针对代理将设备要求公布到***数据存储以在设备上实现）以自动地减轻/修正由状态指示的错误（例如，修复/替换已经遇到错误的设备）。在一个示例中，当代理提供其相关联的设备过载的状态更新时，代理可以向网络添加新设备以卸载处理和/或将过载设备的处理任务移动到另一个网络设备。所收集的状态信息可以作为报告和/或动作的请求由代理提供。

在一些实施例中，实行动作包括允许被配置成实行动作的代理来实行动作。例如，已经确定所接收到的状态指示应当实行动作的代理通知另一个代理（例如，由于代理的触发模式的检测）来实行动作。

图8是图示了用于使用图形模型自动配置计算基础结构的过程的实施例的流程图。在800，接收意图。该意图包括期望的计算基础结构配置。该意图可以指定期望的服务、参考架构和/或网络要求。在一些实施例中，该意图包括在图2的202中接收到的那组要求。在一些实施例中，该意图是由网络运营商发起的业务规则改变或操作状态改变（例如，网络组件被禁用）的结果。在802，计算基础结构被表示为图形表示。在一些实施例中，也在图形表示中表示业务规则和策略元素。例如，处理该意图以确定实现意图中的节点和边缘的图形。在一些实施例中，网络设备由节点表示，而设备之间的关系由边缘表示。在各种实施例中，策略、规则、接口、抽象信息或任何其他适当的网络配置信息经由节点和边缘在图形中表示。如果该意图指示对现有网络配置的改变，则可以处理该意图并且将其表示为对现有图形模型的改变（例如，通过修改节点或关系、删除节点或关系、或添加节点或关系）。如果该意图是网络意图的第一指示，则可以基于该意图来创建新的图形模型。在一些实施例中，直到在意图中指示了足够的配置参数时才部署网络。例如，可以配置网络设备但是并不在线进行。

在804，检测影响代理的触发模式的图形表示的部分。例如，代理与相关节点和边缘的特定触发模式相关联。在一些实施例中，触发模式以编程语言（例如，Python、PERL、Java等）编写。触发模式可以描述图形模型的一部分。在一些实施例中，触发模式定义节点或边缘的特质（例如，类型、属性或标签）。在一些实施例中，触发模式定义特定类型的节点和边缘，并且定义节点和边缘在特定配置中如何相互关联。对图形表示的改变可能使得在先前不存在的图形表示中发生特定模式，从而调用与特定模式相关联的代理。例如，基于检测到指定的节点链和特定类型的关系以及由模式指示的特定次序来调用代理。在一些实施例中，与代理相关联的触发模式在改变图形表示之前匹配图形表示的至少一部分，并且对图形表示的改变修改（例如，改变或删除）图形表示的先前匹配触发模式的部分。这可能导致响应于检测到匹配图形表示部分已被修改而调用代理。例如，模式可以指定两种特定类型的链路节点的特定配置，并且在图形表示中检测该模式。属于与模式匹配的图形部分的图形表示的任何节点的属性的改变可以调用与模式相关联的回调函数。在另一个示例中，移除被用来匹配触发模式的图形表示的一部分的任何元素调用了与触发模式相关联的代理。

在806，调用被调用代理的回调函数。在一些实施例中，代理与触发模式和回调函数相关联。如果检测到代理的触发模式，则调用代理并且调用与代理相关联的回调函数。回调函数执行命令（例如，以实现意图的至少一部分）。例如，更新图形模型，并且通过由对与触发模式相关联的图形表示的适当部分的检测到的改变触发的回调函数来配置网络设备。在一些实施例中，使用触发模式和回调函数的公布-订阅模型，能够递增地实现对网络配置的改变。

在808，如果适用的话，基于代理回调函数的处理结果来更新图形表示。在一些实施例中，回调函数引起图形表示中的节点或边的修改、添加或删除。基于代理回调函数引起的任何改变来更新图形表示。在一些实施例中，由回调函数引起的对图形表示的改变调用一个或多个附加的回调函数。在一些实施例中，图形表示准确地表示任何给定时间的网络配置。可以通过改变图形表示来实现对网络配置的改变，其中改变图形表示触发了代理来实行执行该改变的回调函数。

图9是图示了可以被包括在图形模型中的节点和边缘的实施例的框图。在一些实施例中，计算基础结构的图形模型完全由节点和边缘组成。全部节点可以共享相同的结构，而边缘共享相同的结构。在所示的示例中，节点900包括多个特质，其包括标识符（ID）、类型、标记、标签和属性。在一些实施例中，ID包括唯一的标识符，诸如字符串或整数。ID可以被用来标识图形表示中的节点，并且将其与其他节点和边缘区分开。在一些实施例中，类型描述节点被分类为的不可变类型。类型可以是字符串。在各种实施例中，节点的类型为服务器、交换机、策略、规则、用户或任何抽象概念。在一些实施例中，标记是被用来标识节点的用户友好标题。标记可以是字符串。例如，如果节点的类型为服务器并且其是网络中存在的第三服务器，则节点可以被标记为“server3”。在一些实施例中，标签是被用来将网络组件分组在一起的灵活标识符。例如，用户使用标签来编码不能基于类型分组的组。标签可以被用来编码在与图形表示相关联的图形大纲中不可用的组。标签可以被用来将相同类型的节点子集、不同类型的边缘的组、或节点和边缘的任何组合来分组在一起。标签可以是用户友好的格式，诸如字符串（例如，“high_availability_servers”）。在一些实施例中，属性包括节点或与节点相关联的数据的属性。在一些实施例中，属性包括期望与节点相关联的任何数据的键值列表。例如，属性可以包括与计算机存储器大小或服务器速度有关的信息。属性可以包括遥测数据。

如示出的，边缘902包括多个特质，其包括ID、类型、标记、标签、源、目标和属性。在一些实施例中，网络配置的图形表示中的边缘包括在具有添加了源和目标的情况下与图形表示中的节点相同的特质（例如，ID、类型、标记、标签、属性）。

在一些实施例中，ID包括唯一标识符，诸如字符串或整数。ID可以被用来标识图形表示中的边缘，并且将其与其他节点和边缘区分开。在一些实施例中，类型描述了边缘被分类为的不可变类型。类型可以是字符串。在各种实施例中，边缘具有的类型为“链路”、“接口”、“托管在其上”、“适用于”或任何抽象概念。在一些实施例中，标记是被用来标识边缘的用户友好标题。标记可以是字符串。例如，边缘可以被标记为“hosted_on”，因为边缘的类型为“托管在其上”。在一些实施例中，标签是被用来将网络组件分组在一起的灵活标识符。例如，用户使用标签来编码不能基于类型分组的组。标签可以被用来编码在与图形表示相关联的图形大纲中不可用的组。标签可以被用来将具有相同类型的边缘的子集、不同类型的节点的组、或节点和边缘的任何组合组合在一起。标签可以是用户友好的格式，诸如字符串（例如，“open_connections”）。在一些实施例中，属性包括边缘或与边缘相关联的数据的属性。在一些实施例中，属性包括期望与边缘相关联的任何数据的键值列表。例如，属性可以包括与计算机存储器大小或服务器速度有关的信息。属性可以包括遥测数据。

在一些实施例中，边缘是方向性的并且表示两个节点之间的关系。在一些实施例中，源指代边缘的源/始发节点，并且目标指代边缘的目标/目的地节点。源和目标可以由指代图形表示中的节点的字符串组成。例如，图形模型中的边缘的源和目标包括图形模型中存在的节点的ID。边缘可以表示两个节点之间的单向关系。两个节点之间可以存在多条边。例如，交换节点（例如，类型为“交换机”的节点）具有托管接口节点（从交换节点到接口节点方向的）的关系，而接口节点具有关于交换机节点（从接口节点到交换机节点方向的）的“hosted_on”的关系。如示出的，边缘902是方向性的，其中节点900是其源，并且其目标是其指向的节点。在网络配置图形表示中，每个边缘可以具有源和目标节点。

在一些实施例中，并非需要在创建节点或边缘时指定全部特质（例如，ID、类型、标签等）。可以使用默认特质。例如，给定源和目标，可以推断出边缘类型。在一些实施例中，基于源和目标的节点类型来推断边缘类型。在一些实施例中，随机生成和/或自动生成ID和标记。例如，标记可以递增以标记节点“server_1”、“server_2”等等，因为创建了类型为“服务器”的节点。可以基于类型来确定属性。标签的默认设置可以包括无标签。

在一些实施例中，图形表示允许具有灵活表示不同的概念，而图形元素的结构保持静态。图形表示可以允许鲁棒且可缩放的***。例如，类型策略的节点可以包括将策略描述为使用特定资源池的属性。类型为“policy_applies_to”的边缘表示策略在交换机上实现，该类型为“policy_applies_to”的边缘具有类型为“策略”的节点作为源和类型为“交换机”的节点作为目标。具有类型为“policy_applies_to”的边缘的触发模式的代理可以调用在图形表示的一部分匹配具有类型为“策略”的源节点和具有类型为“交换机”的目标节点的类型为“policy_applies_to”的边缘模式的情况下实现策略的代理，该类型为“policy_applies_to”的边缘具有类型为“策略”的源节点和类型为“交换机”的目标节点。

在一些实施例中，在使用和执行计算基础结构期间收集的遥测数据被映射到对应的图形元素，以（例如，在视觉上）提供以图形模型格式的遥测数据的表示。在一些实施例中，节点或边缘的属性包括从设备收集的遥测数据。例如，存储发送/接收的流量（traffic）的量、错误数量、风扇速度、温度、运行的控制过程的数量或类型、或任何其他适当的操作数据。在一些实施例中，利用实时遥测数据来更新图形模型。用户可以使用查询语言（例如，GraphQL）来访问网络配置图形中的遥测信息或其他信息。在一些实施例中，遥测信息是只读的。遥测数据可以用键值格式存储，其中键包括参数（例如，风扇速度），并且值包括测量的参数值（例如，以每毫秒旋转为单位的风扇速度）。

图10A是图示了网络设备的实施例的示图。示出了两个交换机。在一些实施例中，两个交换机可以经由两者之间的线缆连接。在一些实施例中，所示的示例是用户期望的网络配置。例如，该意图可以指定两个交换机，其具有连接两者的线缆。如示出的，交换机1000被标记为“脊1”，并且交换机1002标记为“叶1”。如示出的，交换机1000的接口被标记为“以太网1/1”，并且交换机1002的接口被标记为“SWP”。

图10B是图示了图形模型的一部分的实施例的示图。在一些实施例中，图形模型部分表示图10A的网络设备配置。节点1004的类型为“交换机”并被标记为“脊1”并且表示图10A的交换机1000。节点1026的类型为“交换机”并被标记为“叶1”并且表示图10A的交换机1002。

如示出的节点1008的类型为“接口”并且标记为“以太网1/1”。边缘1006和1010描述了以太网1/1节点（1008）和脊1节点（1004）之间的关系。类型为“hosted_interfaces”的边缘1006具有作为源节点的节点1004和作为目标节点的节点1008。类型为“hosted_on”的边缘1010具有作为源节点的节点1008和作为目标节点的节点1004。节点1020具有的类型为“接口”并且被标记为“swp1”。边缘1024和1028描述了叶1节点（1026）与swp1节点（1020）之间的关系。类型为“hosted_on”的边缘1024具有作为源节点的节点1020和作为目标节点的节点1026。类型为“hosted_interfaces”的边缘1028具有作为源节点的节点1026和作为目标节点的节点1020。

节点1014具有的类型为“链路”并被标记为“SpineToLink”。该节点与脊1节点和叶1节点的接口有关系。边缘1012和1016描述了以太网1/1节点与spineToLink节点之间的关系。类型为“链路”的边缘1012具有作为源节点的节点1008和作为目标节点的节点1014。类型为“接口”的边缘1016具有作为源节点的节点1014和作为目标节点的节点1008。边缘1018和1022描述了swp1节点与spineToLink节点之间的关系。类型为“链路”的边缘1022具有作为源节点的节点1020和作为目标节点的节点1014。类型为“接口”的边缘1018具有作为源节点的节点1014和作为目标节点的节点1020。

图10C是触发模式的示例。该示例示出了以编程语言（例如，Python）表达的触发模式。在所示的示例中，定义了特定节点和边缘的特定组合和次序。可以使用任何适当的编程语言来定义触发模式。在一些实施例中，所示的示例描述了图10B中所示的图形模型部分的一部分。例如，1060处的“node(type='switch')”描述了图10B的节点1004，1062处的“.out（'hostedinterfaces'）”描述了图10B的边缘1006，并且1064处的“.node（'interface'）”描述了图10B的节点1008。

如示出的触发模式定义了如图10B中所示的从左（图10B的节点1004）到右（图10B的节点1026）的传出关系，而没有描述如图10B中所示的从右到左的传出关系。例如，触发模式仅描述图10B中所示的图形模型部分的一部分。在一些实施例中，如果在图形模型中检测到、添加到图形模型、在图形模型中修改或从图形模型中删除图10B中所示的图形模型部分，则调用与所示的触发模式相关联的代理。

图10D是触发模式的示例。在一些实施例中，在触发模式中指定一个或多个相关数据结构。可以使用标记（例如，节点或边缘的标记特质）来指定一个或多个相关数据结构。在一些实施例中，通过引用在触发模式中指定（例如，通过标记）的数据结构来调用与触发模式相关联的回调函数。例如，如果网络配置图形的一部分与代理的触发模式匹配，则向代理提供到特定节点或边缘的路径。在一些实施例中，特定节点或边缘存在于图形模型的与触发模式相匹配的部分中。利用特定节点或边缘的引用或路径调用了代理的回调函数，从而允许在特定节点或边缘上实现该函数。例如，回调函数包括回调函数中与触发模式中的标记相匹配的标记。该标记允许回调函数在图形模型中的节点或边缘上执行动作，其中图形模型中的节点或边缘与触发模式中的标记节点或边缘相匹配。使用图形模型和标记特质允许轻松传递对数据结构的引用。在一些实施例中，利用对多个数据结构的多个引用来调用回调函数。

在所示的示例中，触发模式在1080处定义“node(type='switch'，label='local_device')”。在一些实施例中，如果图形表示的一部分与触发模式相匹配，与在1080处定义的节点相匹配的节点被标记为“local_device”。关联于与触发函数相关联的代理的回调函数利用“local_device”被定义为输入。如果调用回调函数，则对图形表示中与1080处定义的节点相匹配的节点的引用被传递给回调函数。

图11示出了图形模型的模型大纲（例如，以Python格式）的示例。在一些实施例中，网络的图形模型具有相关联的图形模型大纲。可以在大纲中定义节点与边缘之间的有效节点、边缘和关系。例如，可以仅允许第一类型的节点与第二类型的节点共享边缘。无效的关系或节点可以调用回调函数。例如，回调函数可能向用户提供错误或丢弃最后接收的意图改变。大纲可以是特定于域的；可以为不同的网络架构存在不同的大纲。

模型大纲1100是用Python编写的，但是任何计算机语言可以被用来实现模型大纲。该示例示出了典型的叶-脊网络架构的图形模型大纲。所公开的***可以将个体设计大纲视为不透明的，并且仅在只包括节点和关系的图元模型处进行操作。如示出的，模型大纲1100描述了允许的数据类型和值。如示出的，1120、1122、1124和1126包括该大纲下的允许关系。例如，类型为“composed_of”的边缘必须具有类型为“link”的源节点和类型为“link”的目标节点。类型为“part_of”的边缘必须具有类型为“link”的源节点和类型为“link”的目标节点。类型为“hosted_interfaces”的边缘必须具有类型为“system”的源节点和类型为“interface”的目标节点。

图12A是图示了代理创建流程的实施例的流程图。在一些实施例中，创建代理以基于触发模式实行回调函数。每个跟踪不同触发模式的多个代理可以一起工作以基于计算基础结构的图形模型中的改变来适当地配置网络。在一些实施例中，使用单独代理的模块化方法增加了处理意图改变的效率。

在一些实施例中，一组预先创建的代理与特定网络架构（例如，叶-脊架构）相关联。例如，一组代理和大纲可以与具有叶-脊架构的网络相关联。每种网络架构类型可以具有对应的大纲和一组代理。在一些实施例中，为网络定制大纲或一组代理。可以通过创建或修改代理来向网络配置***添加特征。例如，可以通过编写逻辑以添加代理来容易地缩放***。

示出的示例图示了创建代理的过程。在1200处，定义触发模式。该触发模式可以包括计算基础结构的图形模型的一部分。代理可以由边缘、节点、属性或网络配置图形的任何方面触发。在一些实施例中，代理包括多个触发模式。在一些实施例中，每个代理具有单个触发模式。代理可以将其触发模式作为查询注入管理服务器（例如，图1的管理服务器102）中的查询引擎。在1202处，定义回调函数。在一些实施例中，回调函数基于触发模式定义要采取的动作。例如，代理可以与类型为“链路”的节点的触发模式相关联，并且具有指派IP地址的回调函数。如果将类型为“link”的节点添加到图形模型，则代理可以使得回调函数指派IP地址。在一些实施例中，回调函数将图形模型的节点或边缘作为输入。例如，至少部分地基于图形模型的与触发模式相匹配的部分中的节点或边缘来执行该函数。

在一些实施例中，代理包括回调函数的集合。例如，可以基于是否将与触发模式相关联的图形模型的一部分添加到图形模型中、在图形模型中修改或从图形模型中删除来执行不同的函数（例如，图形模型的一部分是否被改变以匹配触发模式，图形模型的与触发模式匹配的部分中的边缘或节点的属性被改变，或者与触发模式匹配的图形模型的一部分被改变成不再与触发模式匹配）。代理可以存储多个函数，其中基于下述各项来执行函数：与触发模式相关联的图形模型的一部分中的改变的类型（例如，“添加”、“修改”或“删除”）、改变的数据结构的类型、改变的数据结构的位置、对数据结构的参考/路径或任何其他因素。例如，触发模式可以包括类型设备的节点，其具有类型链路的边缘，其将它连接到类型链路的节点。一个回调函数可以定义在类型设备的节点改变属性的情况下要执行的动作，而另一个回调函数定义在删除了类型链路的节点的情况下要执行的动作。如果触发模式定义了包括相同类型的两个节点的模式，则可以基于哪个节点被改变来调用不同的回调函数。

代理可以在配置网络时担任各种角色。在一些实施例中，资源分配代理与触发模式相关联，该触发模式表示当一个或多个元素存在于网络中时需要分配资源的一个或多个网络元素。与资源分配代理相关联的回调函数可以执行分配一个或多个网络元素所需的资源的动作。例如，可以改变联网配置图形以将线缆添加到网络。调用与被创建以添加线缆的特定节点和边缘的触发模式相关联的资源分配代理。调用与资源分配代理相关联的回调函数，从而引起分配线缆所需的资源。

在一些实施例中，代理被用来确定图形中的改变是否与关联于图形的图形大纲一致。语义证实代理可以基于该图形大纲来确定该图形是否准备好用于下游处理。如果图形不满足图形大纲中规定的规则，则改变可能是不适用的。例如，如果IP地址未被指派或无效，则无法呈现某些设备配置。例如，语义证实代理可以与边缘类型为“instantiated_by”的触发模式相关联。图形大纲可以指示类型为“instantiated_by”的边缘必须具有类型为“virtual_network”的源节点和类型为“vn_instance”的目标节点。如果将类型为“instantiated_by”的边缘添加到图形模型中，则可以触发语义证实代理。语义证实代理的相关联的回调函数可以确定边缘的源节点的类型是否是“virtual_network”以及边缘的目标节点的类型是否是“vn_instance”。如果源节点和目标节点不是图形大纲中定义的预期类型，则可以向用户提供错误消息。

在一些实施例中，一旦检测到模式，代理就实行与触发模式相关联的检查。例如，代理实行对类型为“switch”的节点周围的节点和边缘的检查，以确保存在所需的节点和边缘。在一些实施例中，代理在网络组件以不期望的范围进行操作的情况下引发警报或调整网络配置。例如，代理与类型为“服务器”的节点的属性的触发模式相关联。如果节点的属性的改变指示服务器正在高温下操作，则可以调用遥测数据代理的相关联的回调函数来关闭与类型为“服务器”的节点相关联的服务器。

图12B是图示了用以检测和响应异常的过程的实施例的流程图。在一些实施例中，该***被用来收集网络遥测数据、分析网络、并且在闭环中适当地进行响应。可以从原始遥测数据中提取异常、可操作信号、影响分析或任何其他适当的信息。例如，在（例如，经由遥测数据）检测到服务、设备或功能组件断电（outage）之后，确定受影响的消费者或确定和收集所需的附加遥测数据集合。基于该分析，可以执行用以通知受影响方或补救异常的适当动作。

在1210处，确定图形表示的一部分与触发模式相匹配。在一些实施例中，触发模式定义一组受管理的网络元素，其中针对异常来监控受管理的网络元素。例如，触发模式包括属于特定租户的特定虚拟网络的流量所遍历的一组链路。在1212处，计算该组网络元素的聚合属性。在各种实施例中，计算标准偏差、最小值、最大值、平均值或任何适当的统计量或属性。例如，可以创建每个链路上的流量的最近历史时间序列，并且通过水印聚合器运行，以确定运行超过80％利用率长达多于30秒的链路的数量。在1214处，将条件逻辑应用于结果以检测异常。在一些实施例中，预定义的条件逻辑包括聚合属性的阈值（例如，最大值或最小值），并且在计算的聚合属性基于阈值是异常的情况下检测到异常。例如，如果该组链路中多于百分之五的链路运行超过80％利用率长达多于30秒，则生成异常。在1216处，基于异常来收集附加的遥测数据。例如，确定对该组链路上的流量有贡献的完整的一组租户。在1218处，确定受异常影响的一方。例如，标识受异常影响的其他虚拟网络和租户。在1220处，基于异常来执行适当动作。例如，流量被重定向到不同的链路，或者要求受影响的租户降低链路的利用率。

在一些实施例中，闭环遥测收集、分析和响应过程是自动化的。在一些实施例中，基于时间间隔来连续监控（例如，每五秒计算的）该组网络元素的聚合属性。

在一些实施例中，代理与定义一组受管理元素的触发模式相关联。在一些实施例中，触发模式还定义了该组受管理元素的属性。例如，指代多个传输字节的“transmit_bytes”是类型为“链路”的节点的属性。代理的相关联的触发模式通过指定该组链路的“transmit_bytes”属性来指定属于特定租户的特定虚拟网络的流量所遍历的一组链路的传输字节。在一些实施例中，基于触发模式中指定的属性来执行函数以计算聚合属性。例如，与指定类型为“链路”的一组指定节点的“transmit_bytes”属性的触发模式相关联的代理与确定运行超过80％利用率长达多于30秒的链路百分比（由类型为“链路”的一组指定节点表示的链路之外）的回调函数相关联。

在一些实施例中，代理与一组函数相关联，这些函数计算图形表示中的被管理元素的聚合属性、将条件逻辑应用于聚合属性、检测异常、以及存储异常数据（例如，中继存在异常或中继有关异常的细节的信息，诸如运行超过80％利用率长达多于30秒的链路的百分比）。例如，回调函数可以确定运行超过80％利用率长达多于30秒的链路百分比是否超过阈值。如果确定百分比超过阈值，则可以确定存在异常并且存储异常数据。例如，异常数据被存储为节点的属性（例如，“aggregated_traffic”是类型为“链路”的节点的属性，其指代运行超过80％利用率长达多于30秒的链路的百分比）。在一些实施例中，异常数据触发附加的代理。例如，附加的代理与触发模式相关联，该触发模式指定属于特定租户的特定虚拟网络的流量所遍历的一组链路的“aggregated_traffic”属性。附加的代理可以触发附加的遥测。例如，定义与该附加的代理相关联的函数以确定对该组链路上的流量有贡献的完整的一组租户。在一些实施例中，单独的代理与指定一组受影响方的触发模式相关联。例如，触发模式指定具有虚拟网络的租户，这些虚拟网络具有托管在服务器上的端点，这些端点经由具有超过阈值的聚合流量的链路进行连接（例如，类型为“租户”的节点，其与类型为“virtual_network”的节点共享边缘，其中类型为“virtual_network”的节点与类型为“endpoint”的节点共享边缘，该类型为“endpoint”的节点与类型为“server”的节点共享类型为“hosted_on”的边缘，其中类型为“server”的节点与类型为“链路”的节点共享边缘，其中类型为“链路”的节点具有“aggregated_traffic”的属性。）单独的代理可以执行警告租户的相关联的函数。

在一些实施例中，无论是否检测到异常，都保存聚合属性（例如，作为节点属性）。基于聚合属性触发的回调函数可以包括条件性（例如，在聚合属性值未被确定为异常的情况下将不调用该函数）。

在一些实施例中，1212、1214、1216、1218和1220以图形表示来表示。在一些实施例中，处理阶段的工作流程（例如，在1212、1214、1216、1218和1220处描述的步骤）在有向非循环图形中表示。在一些实施例中，每个步骤被表示为节点。所示流程的次序经由有向边缘表示。例如，类型为“process_step”的节点包括有关计算网络元素的聚合属性的信息，并且具有指向类型为“process_step”的另一个节点的有向边缘，该类型为“process_step”的节点包括关于将条件逻辑应用于聚合属性的信息，从而引起聚合属性计算步骤在条件逻辑步骤之前实行。在一些实施例中，处理阶段的工作流程（例如，在1212、1214、1216、1218和1220处描述的步骤）被表示为图形表示的一部分，并且是计算基础结构的图形表示的部分。在一些实施例中，步骤的序列在单独的图形中表示。

代理可以订阅表示阶段的图形元素，并且通过执行所需的处理来对它们作出反应。在一些实施例中，代理与表示处理阶段或步骤的图形元素的触发模式相关联。在一些实施例中，代理具有相关联的回调函数，其执行由图形元素定义或参数化的处理。例如，如果在类型为“链路”的指定节点上请求数据分析，则可以创建一系列类型为“process_step”的节点，这些节点源自类型为“链路”的指定节点。该系列节点可以包括单个链。例如，创建从类型为“link”的指定节点指出的边缘，并且将类型为“link”的指定节点与随后新创建的类型为“process_step”的节点连接，其中新创建的类型为“process_step”的节点具有描述了计算聚合属性的公式（formula）的节点属性。在创建具有描述了用以计算聚合属性的公式的节点属性的类型为“process_step”的节点之后，创建从聚合属性计算节点指出的新边缘，并且将聚合属性计算节点与随后创建的类型为“process_step”的节点结合起来，该类型为“process_step”的节点具有包括阈值的节点属性。在一些实施例中，创建类型为“process_step”的节点导致触发了与触发模式相关联的代理，该触发模式指定类型为“process_step”的节点。可以一次一个地创建类型为“process_step”的节点，从而以期望的次序触发代理。

例如，具有与类型为“链路”的指定节点的“transmit_bytes”属性相关联的触发模式的代理可以与回调函数相关联，该回调函数确定类型为“链路”的指定节点是否具有指向类型为“process_step”的节点的传出边缘，并且如果类型为“link”的指定节点与类型为“process_step”的节点不共享传出边缘，则将类型为“link”的节点的“transmitted_bytes”属性值保存成类型为“process_step”的节点的属性。“transmit_bytes”属性值可以保存在类型为“process_step”的节点的“base_calculation_value”属性下。在一些实施例中，通过触发模式对聚合属性的计算进行参数化（例如，传递传输字节的属性在触发模式中被定义，并且被用作计算过度使用链路的百分比的输入）。例如，与指定类型为“process_step”的节点的“base_calculation_value”属性的触发模式相关联的代理可以使得与代理相关联的回调函数基于在“base_calculation_value”属性下保存的值和在类型为“process_step”的节点的“formula”属性下保存的公式来执行聚合属性的计算。在一些实施例中，聚合属性被保存为节点的属性（例如，作为“aggregate_property”属性值）。在一些实施例中，通过将值保存为节点或边缘属性，在处理阶段之间传递值。

创建具有指定阈值的节点属性的类型为“process_step”的第二节点可以触发与指定节点的“threshold_value”的属性的触发模式相关联的代理。与代理相关联的回调函数可以基于类型为“process_step”的第二节点的“threshold_value”属性值和类型为“process_step”的第一节点的“aggregate_property”属性值来确定是否存在异常。如果检测到异常，则可以更新类型为“process_step”的第二节点的“异常”属性以指示存在异常。在各种实施例中，处理步骤由图形元素（例如，节点、属性和边缘）和代理的各种配置来执行。

图13A是图示了包括分支的图形模型的一部分的实施例的示图。图形模型部分图示了网络设备和组件的树模式。在该示例中，示出了节点的标记并且示出了边缘的类型。域节点（例如，具有标记“域”的节点）1304具有分别具有环回节点1302和设备节点1300的类型为“hosted_interfaces”和“composed_of_systems”的传出边缘（例如，节点1304是边缘的源节点）。设备节点1300具有与remote_interfaces节点1310的类型为“interfaces”的传出关系、与接口节点1312的类型为“hosted_interfaces”的传出关系、与remote_device节点1314的类型为“host”的传出关系、与链路节点1308的类型为“链路”的传出关系，以及与remote_domain节点1306的类型为“part_of_domain”的传出关系。Remote_device节点1314具有与remote_loopback节点1316的类型为“hosted_interfaces”的传出边缘。

图13B示出了代理的实现方式的示例。在一些实施例中，图13B实现与触发模式相关联的代理，该触发模式匹配图13A中所示的图形模型部分。例如，如果在图形模型中检测到图13A中所示的图模型部分，则将调用所示的回调函数。尽管以下示例利用Python编程语言，但是在各种其他实施例中可以利用其他编程语言。在所示的示例中，定义了触发模式和回调函数。

在1356处，定义触发模式。在所示的示例中，被标记为“域”和“设备”的节点分别在1350和1353处定义。这些节点对应于如图13A中所示的节点1304和1300。在所示的示例中，不具有传出边缘的节点不会单独声明为在另一个节点的定义的部分外面。例如，在1350处的“node（'domain'，name='domain'，domain_type='autonomous_system'）”声明图13A的域节点1304，在1351处的“.out（'composed_of_systems'）”定义来自图13A的域节点1304的类型为“composed_of_systems”的传出边缘，并且在1352处的“.node（'system'，name='device'）”将图13A的节点1300定义为类型为“composed_of_systems”的边缘的目标节点。在所示的示例中，标记被用来往回指代定义的数据结构。例如，在1353处的“node(name='device')”被用来指代在1352处读取“.node（'system'，name='device'）”的行中首先定义的节点。

代码声明了节点、其传出边缘和传出边缘的目标节点。例如，所示示例中的第二行声明了类型为“domain”的节点和名称（例如，标记）“domain”。以“node”开始的行声明了一个节点。以“.out”、“.node”和“.where”开始的行在以“node”开始的行之后，并且指代以“node”开始的行中声明的节点。以“.out”开始的行指示来自节点的传出边缘。以“.node”开始的行跟随以“.out”开始的行，并且指示以“.out”开始的行中定义的边缘的目标节点。以“.where”开始的行描述了指代节点的细节。

在1370处，定义了回调函数。在一些实施例中，如果将与在1356处定义的触发模式相匹配的图形模型的一部分添加到图形模型、在图形模型中修改或从图形模型中删除，则执行回调函数。

图14A是图示了图形模型的一部分的实施例的示图。设备节点（例如，具有标记“设备”的节点）1400具有类型为“hosted_on”的传出边缘，其具有remote_device节点1402；具有remote_interface节点1404的“接口”；具有链路节点1406的“链路”；以及具有接口节点1408的“hosted_interfaces”。

图14B示出了代理的实现方式的示例。在1400处标识实现代理的类，其中代理可以具有一个或多个触发模式。示出的类定义了各种可重用的函数。虽然该示例是用Python编写的，但是代理使用的编程语言特征没有限制。触发模式在1420处被标识。在一些实施例中，触发模式匹配图14A中所示的图形模型的部分。例如，在1450处的“node（'system'，name='device'）”描述了图14A的设备节点1400；在1452处的“.out（'hosted_interfaces'）”描述了图14A的类型为“hosted_interfaces”的边缘；以及在1454处的“.node（'interface'，name='interface'）”描述了图14A的接口节点1408。在1456处定义与代理相关联的回调函数。在一些实施例中，无论何时与在1420处定义的触发模式相匹配的图形模型的一部分被添加到图形中、从图形中移除或在图形中更新，都调用回调函数。

图15是图示了用于调用回调函数的过程的实施例的流程图。在一些实施例中，该过程实现图8的804和806。在一些实施例中，该过程由图16的代理管理器1602实现。在1500处，确定图形是否被改变。该图形可以基于所接收到的意图或者基于调用的回调函数而改变。在一些实施例中，由一个代理引起的对图形的改变触发另一个代理。如果图形未被改变，则该过程结束。在一些实施例中，在网络是活动（例如，期望被配置）的同时重复该过程。如果图形已被改变，则在1502处，确定图形中的改变是否影响一个或多个代理。

在一些实施例中，如果在图形表示中检测到、向图形表示添加、在图形表示中更新或从图形表示中移除了与代理的触发模式相关联的图形表示的一部分，则对图形表示的改变调用代理。在一些实施例中，如果对图形表示的改变使得图形表示的一部分与特定触发模式相匹配，则发生检测或添加图形表示与特定触发模式相匹配的一部分，其中图形表示的该部分先前并不匹配该特定触发模式。例如，如果图形中的现有节点和边缘被修改使得图形的一部分与特定触发模式相匹配，则在图形表示中检测与特定触发模式匹配的图形表示的一部分。如果将与特定触发模式相匹配的新图形部分添加到现有图形，则将与特定触发模式相匹配的图形表示的一部分添加到该图形表示。

在一些实施例中，如果图形表示中的改变修改图形表示的一部分内与改变之前的特定触发模式相匹配的节点或边缘并且该部分继续匹配改变后的特定触发模式，则更新与图形表示中的触发模式相匹配的图形表示的一部分。

在一些实施例中，如果对图形表示的改变修改先前与触发模式相匹配的图形表示的部分使得图形表示的一部分不再与触发模式相匹配，则从图形表示中删除与触发模式相关联的图形表示的该部分。例如，可以从先前与触发模式相匹配的图形部分中删除节点或边缘、可以更改先前与触发模式相匹配的图形部分中的节点或边缘（例如，改变诸如类型之类的特质）、或者可以完全删除先前与触发模式相匹配的图形部分。

如果图形中的改变不影响一个或多个代理，则该过程结束。如果图形中的改变影响一个或多个代理，则在1504处，调用（一个或多个）回调函数。例如，调用与一个或多个代理相关联的一个或多个回调函数。在一些实施例中，向回调函数提供关于是否在图形表示中检测、向图形表示添加、在图形表示中更新或从图形表示中移除与触发模式相关联的图形表示的一部分的指示。在一些实施例中，基于指示来调用不同的回调函数，以便基于该指示实行不同的动作。例如，如果将特定节点关系模式添加到网络配置图形，则回调函数分配资源（例如，为类型为“链路”的节点分配IP地址）。如果移除了该模式，则回调函数将移除该节点的资源请求。

图16是图示了管理服务器的实施例的示图。管理服务器1600可以被用来实现图1的管理服务器102。在所示的示例中，管理服务器1600包括代理管理器1602和代理1604、1606和1608。在各种实施例中，管理服务器包括60、200、1000或任何适当数量的代理。代理可以包括触发模式和在存在触发模式的情况下要调用的对应的回调函数。如示出的，代理1608与触发模式1610和回调函数1612相关联。

在一些实施例中，诸如代理管理器1602之类的中央软件组件被用来通过跟踪对网络配置的图形表示的改变来跟踪对网络配置的全部改变，其中图形表示准确地表示网络的实时状态。在一些实施例中，代理管理器1602包括查询引擎。如示出的，代理管理器1602从分布式数据存储1614接收输入。在一些实施例中，网络配置的图形表示存储在分布式数据存储中。输入可以包括当前网络配置图形（例如，网络配置的图形表示）。在一些实施例中，代理管理器1602将网络配置图形的当前状态与网络配置图形的先前状态进行比较以确定图形中的改变。在一些实施例中，代理管理器1602实现804图8的（检测图形表示的影响触发模式或代理的部分）。如果网络配置图形已经改变，则代理管理器1602仅向相关代理通知该改变。基于其触发模式来确定相关代理（例如，图形中的改变是否影响代理的触发模式）。例如，利用“公布-订阅”模型，其中代理订阅了影响与代理相关联的触发模式的图形中的改变。在一些实施例中，基于触发模式来代替中央改变记录组件来调用代理。

可能需要基于网络配置图形来实行各种动作。在各种实施例中，图形中的改变引起要从设备收集的状态、要删除的链路、要创建的节点或任何其他适当的动作。可以经由回调函数来实行动作。在一些实施例中，特定触发模式的查询运行一次。在指定了触发模式之后，如果在图形模型中匹配其触发模式，则仅通知相关联的代理图形中的改变。在一些实施例中，实时查询和图形表示允许***是鲁棒和可缩放的。在一些实施例中，***的框架不改变；添加代理、节点或边缘以实现新特征。

在所示的示例中，代理向分布式数据存储1614提供输入。当调用相关联的回调函数时，代理可能会引起对网络配置的改变。该改变可以存储在网络配置图形中。在一些实施例中，代理实现图8的808（如果适用的话，基于代理回调函数的处理结果来更新图形表示）。

虽然出于理解清晰的目的已经比较详细地描述了前述实施例，但是本发明并不限于所提供的细节。存在实现本发明的许多替换方式。所公开的实施例是说明性的而不是限制性的。

Claims (20)

1.一种用于配置计算基础结构的方法，其包括：

将所述计算基础结构的至少一部分表示为包括计算基础结构节点和计算基础结构边缘的计算基础结构元素的图形表示，其中所述计算基础结构节点表示网络交换机设备并且所述计算基础结构边缘表示连接所述网络交换机设备的连接；

检测计算基础结构元素的所述图形表示中的由于对针对计算机网络基础结构的声明性要求的改变的改变；

响应于检测到计算基础结构元素的所述图形表示中的所述改变，标识与计算基础结构元素的所述图形表示的所改变的部分相匹配的触发模式；

响应于标识出所述触发模式，使用标识出的所述触发模式从多个功能中选择功能，其中所选择的所述功能被配置成自动配置所述网络交换机设备以实现所述声明性要求的至少一部分；以及

配置所述网络交换机设备，其中配置所述网络交换机设备包括执行所选择的所述功能以自动实现所述声明性要求的所述至少一部分。

2.根据权利要求1所述的方法，其中所述计算基础结构节点包括以下各项中的一个或多个：标识符、类型、标记、标签和属性。

3.根据权利要求1所述的方法，其中所述计算基础结构边缘包括以下各项中的一个或多个：标识符、类型、标记、标签、源节点、目标节点和属性。

4.根据权利要求2所述的方法，其中标签被用来编码在所述图形表示的图形大纲中不可用的一组计算基础结构元素。

5.根据权利要求1所述的方法，其中图形表示查询模式定义所述计算基础结构节点或所述计算基础结构边缘的类型、标记、标签或属性。

6.根据权利要求1所述的方法，其中图形表示查询模式定义了相互关联的一组计算基础结构节点和计算基础结构边缘。

7.根据权利要求1所述的方法，其中查询代理至少部分地基于计算基础结构元素的所述图形表示中的所述改变来执行所选择的所述功能。

8.根据权利要求7所述的方法，其中计算基础结构元素的所述图形表示基于至少部分地由所述查询代理执行的所选择的所述功能所引起的对所述计算基础结构的改变而被修改。

9.根据权利要求7所述的方法，其中由所述查询代理执行的所选择的所述功能使得附加的查询代理执行附加的功能。

10.根据权利要求1所述的方法，其包括向查询代理提供对计算基础结构元素的所述图形表示中的一个或多个计算基础结构元素的一个或多个引用。

11.根据权利要求10所述的方法，其中基于图形表示查询模式中的一个或多个计算基础结构元素的指示，将所述一个或多个引用提供给所述查询代理。

12.根据权利要求10所述的方法，其中所述查询代理至少部分地基于计算基础结构元素的所述图形表示中的所述改变以及对计算基础结构元素的所述图形表示中的一个或多个计算基础结构元素的一个或多个引用来执行所选择的所述功能。

13.根据权利要求10所述的方法，其中图形表示查询模式包括所述计算基础结构节点或所述计算基础结构边缘的标记或属性，并且由所述查询代理执行的功能包括所述计算基础结构节点或所述计算基础结构边缘的标记或属性。

14.根据权利要求1所述的方法，其包括向查询代理提供下述指示：计算基础结构元素的所述图形表示中的所述改变是否使得所述图形表示的与图形表示查询模式不匹配的一部分与所述图形表示查询模式相匹配、使得所述图形表示的与所述图形表示查询模式相匹配的一部分中的计算基础结构元素的属性发生改变、或者使得所述图形表示的与所述图形表示查询模式相匹配的一部分不再与所述图形表示查询模式相匹配。

15.根据权利要求1所述的方法，其包括向查询代理提供对图形表示查询模式中的一个或多个计算基础结构元素的引用，以及下述指示：计算基础结构元素的所述图形表示中的所述改变是否使得所述图形表示的与所述图形表示查询模式不匹配的一部分与所述图形表示查询模式相匹配、使得所述图形表示中的与所述图形表示查询模式相匹配的一部分中的计算基础结构元素的属性发生改变、或者使得与所述图形表示的与所述图形表示查询模式相匹配的一部分不再与所述图形表示查询模式相匹配。

16.根据权利要求1所述的方法，其中查询代理确定计算基础结构元素的所述图形表示中的所述改变是否符合图形大纲。

17.根据权利要求1所述的方法，其中遥测数据存储在所述图形表示中。

18.根据权利要求1所述的方法，其中查询代理基于存储在所述图形表示中的遥测数据来执行功能。

19.一种计算基础结构配置***，其包括：

处理器，其被配置成：

将所述计算基础结构配置***的至少一部分表示为包括计算基础结构节点和计算基础结构边缘的计算基础结构元素的图形表示，其中所述计算基础结构节点表示网络交换机设备并且所述计算基础结构边缘表示连接所述网络交换机设备的连接；

检测计算基础结构元素的所述图形表示中的由于对针对计算机网络基础结构的声明性要求的改变的改变；

响应于检测到计算基础结构元素的所述图形表示中的所述改变，标识与计算基础结构元素的所述图形表示的所改变的部分相匹配的触发模式；

响应于标识出所述触发模式，使用标识出的所述触发模式从多个功能中选择功能，其中所选择的所述功能被配置成自动配置所述网络交换机设备以实现所述声明性要求的至少一部分；以及

配置所述网络交换机设备，其中为了配置所述网络交换机设备，所述处理器被配置为执行所选择的所述功能以自动实现所述声明性要求的所述至少一部分。

20.一种有形计算机可读存储介质，所述有形计算机可读存储介质存储用于配置计算基础结构的计算机程序产品，所述计算机程序产品包括计算机指令，所述计算机指令用于：

将所述计算基础结构的至少一部分表示为包括计算基础结构节点和计算基础结构边缘的计算基础结构元素的图形表示，其中所述计算基础结构节点表示网络交换机设备并且所述计算基础结构边缘表示连接所述网络交换机设备的连接；

检测计算基础结构元素的所述图形表示中的由于对针对计算机网络基础结构的声明性要求的改变的改变；

响应于检测到计算基础结构元素的所述图形表示中的所述改变，标识与计算基础结构元素的所述图形表示的所改变的部分相匹配的触发模式；

响应于标识出所述触发模式，使用标识出的所述触发模式从多个功能中选择功能，其中所选择的所述功能被配置成自动配置所述网络交换机设备以实现所述声明性要求的至少一部分；以及

配置所述网络交换机设备，其中为了配置所述网络交换机设备，所述计算机指令执行所选择的所述功能以自动实现所述声明性要求的所述至少一部分。

Images