基于意图的网络：是否需要推翻和替换我们的现有网络？

基于意图的网络最近十分火爆，主要是由于思科密集的营销活动。那么基于意图的网络究竟是什么呢？

Gartner的Andrew Lerner将基于意图的网络解决方案（IBNS）定义为具有以下特征的系统：

• 转化和验证：系统采用更高级别的业务策略作为终端用户的输入，并将其转换为必要的网络配置。然后，系统生成并验证所得到的设计和配置的正确性。
• 自动实施：该系统可以在现有的网络基础设施上配置适当的网络更改。这通常是通过网络自动化和网络编排来完成的。
• 网络状态意识：系统为其管理控制下的系统提取实时网络状态，并且与协议和传输无关。
• 保证和动态优化/修复：系统持续地（实时地）验证系统的原始业务意图是否得到满足，并且可以在期望的意图未得到满足的情况下采取纠正措施（例如拥塞通信、修改网络容量或通知）。

当我们分析这四个特征并尝试将其映射到目前的情况时，由声明语言和闭环编排（CLO）驱动的适当的编排器将满足IBNS的要求。此外，如果是这种情况，则不需要推翻和替换现有网络。我们所需要的只是应用适当的编排规则。下面我们来分析一下。

声明性编排

首先来讨论“转化和验证”和“自动实施”。这两点是描述由声明语言驱动的编排器的。在声明语言中，我们声明了我们想要实现的内容，并且将使用编排器的解析器来实现它。有一个例子能够很好地说明这一点，即需要进行南北（NS）和东西（ES）通信的应用程序。下面看一下它是如何工作的。

在数据中心，我们有CRM（crm）应用程序侦听TCP 8888并托管在虚拟机（vm_host_1）上。此CRM应用程序需要与内部应用程序（app_int）和外部应用程序（app_ext）进行通信。在这个例子中，我们将这种通信视为“东西”（E-W）和“南北”（N-S）。内部应用程序正在侦听TCP 8080，外部应用程序正在侦听TCP 9000。在N-S方向上我们有防火墙，在E-W上我们有路由器。

防火墙和路由器的存在意味着需要执行一些特定的配置。在防火墙的情况下，假设它是防火墙规则，在路由器的情况下，假设它是一个访问列表。具体的实施过程无关紧要，超出了本文讨论的范围。重要的是我们有两种不同的实施方法。今天它是一个FW和访问列表，明天可能会被ACI结构或其他东西取代。我们需要找到一种方法来描述/声明我们想要实现的目标。这是TOSCA驱动的DSL可以派上用场的地方。

简而言之，TOSCA是一种以拓扑形式描述服务的语言，该拓扑基于节点和关系。它是为描述云应用程序而构建的，但其语法非常适用于网络环境。毕竟，网络环境只不过是节点和关系的组合，不是吗？

下面看一下如何使用基于TOSCA的DSL解决我们的问题。 Cloudify的DSL利用了节点和关系的概念。关系是关键，因为这种关系将反映意图并“隐藏”实现给定连接所需的必要操作：
https://gist.github.com/astianseb/563706e919638749fe0ddc7e30a55902

在模型中，我们找到以下节点：

• vm_host_1
• CRM
• app_int
• app_ext

和关系：

• cloudify.relationship.connected_ew
• cloudify.relationship.connected_ns

我们的CRM应用定义：

我们可以看到，我们正在声明我们想要实现的目标：将crm应用程序连接到app_int和app_ext而已！

让我们花一点时间来理解关系定义，因为这就是“secret sauce”。下面说明如何实施给定的关系：

我们可以看到，我们正在利用rtr_plugin以实现连接创建和删除方法。将来，我们可能需要将路由器从厂商A更改为B，并且我们的模型仍将保留，只需要更改实施。这是一个很大的优势，因为它带来了合适的基础设施抽象。

简而言之，我们所做的只不过是Gartner创建IBNS所需要的：通过Cloudify DSL进行“转化和验证”以及通过Cloudify编排器进行“自动实施”。

剩下的两个：“网络状态意识”和“保证和动态优化/修复”？这就是闭环编排架构发挥作用的地方。为了获得网络状态，我们需要收集表示状态的指标，还需要策略实施来动态更改此状态并提供修复措施。

闭环编排

闭环编排（CLO）也称为反馈回路，其目的是为了响应一个事件（或一组事件）以改变系统状态。为了改变系统状态，我们经常需要了解它的模型，这是一个合适的编排器的角色。

仔细看CLO概念。首先，我们需要一个编排的对象，是我们需要观察并可能发生变化的IT系统元素。它可以像运行某些应用程序的单个主机服务器一样简单，也可以像应用程序集群那样复杂。它可以是单个虚拟防火墙，也可以是包括多个虚拟防火墙、负载均衡器和虚拟边缘路由器的完整的虚拟安全外围。我们为什么要在这里讨论虚拟？因为VNF在性质上比PNF更具动态性，而CLO与它们的关系更密切，但是也可能存在CLO与PNF相关的情况。

接下来我们需要收集指标。哪些指标？这取决于系统。它们可以像CPU或VPN用户的数量一样简单，但也可以是基于多个参数计算的更复杂的“复合指标”。简而言之，指标是衡量给定系统的关键。目前越来越常见的是大数据分析，它根据历史数据和复杂的启发式算法计算这些指标。

一旦我们有了指标之后，我们就需要根据它来决定做什么，这就是策略。策略引擎观察/获取指标、处理指标并强制执行操作。动作表示一些生命周期动作，它将改变编排对象的状态。举一个NFV的例子就是“scale-out”/”scale-in”，“heal”甚至“change placement”。策略引擎不负责执行操作。它只强制执行给定的策略并告诉编排器该做什么。编排器作用于编排对象并实施给定的生命周期动作。

我们可以讨论指标集合和策略引擎是否应该成为编排系统中的一部分。有些情况下这是可能和预期的，但没有系统的指导。举个例子就是它们需要解耦以提供功能的深度和广度。这尤其适用于指标收集。如果我们的系统非常复杂并且需要基于大数据分析计算的复合指标，那么当该系统位于编排器外部时会更好。策略引擎也是如此。市场上有很多策略引擎，如果有人习惯了某些策略引擎，那么为什么要强迫他使用不同于他习惯的东西呢？ 重要的是开放性。优秀的编排器应该能够与外部指标收集和策略引擎集成。

Cloudify拥有良好的闭环编排记录。几年前，当这个话题还不常见时，Cloudify在Cloudify Manager中实现了CLO。该系统基于Diamond代理和Riemann策略引擎的指标流：
https：//docs.cloudify.co/4.3.0/about/manager_architecture/metrics-flow/
那时候这是一种非常创新的方法。它允许我们创建动态系统，其中状态根据给定的指标进行更改。

总结

我们使用现有的概念演示了基于意图的网络系统（IBNS）。为什么这很重要？因为我们可以将基于意图的网络概念应用于现有网络。如果我们处理具有良好API和编程接口的网络元素，我们可以使用声明语言驱动的编排器来编排它们，并在反馈回路中管理它们的生命周期。对于电信公司来说，这是无价之宝。我们不需要推翻和替换现有网络以使其更加智能化，我们只需要智能系统来管理它们。