The Apstra Operating System Architecture Overview

执行摘要

AOS在供应商不可知的环境中提供了强大的、意图驱动的网络服务自动化，它作为一个易于使用的服务来响应消费者指定的意图。网络设备提供数据包，AOS服务提供应用程序工作负载。
根据大量的研究，70-80%的停机是由于应用于生活系统的配置更改，而不是由于初始部署。最初的一次性部署可以被看作是“Hello World”应用程序；随着系统的发展，出现了真正的复杂性。在AOS中，配置、遥测和期望都是以幂等的方式从单一的真实源（意图）派生出来的，因此初始部署和变更管理之间没有实现上的区别。

导言

本文的目标是介绍AOS的总体结构和操作，以便了解它可以为您提供哪些开箱即用的功能，以及如何扩展它。让我们从一些定义开始。AOS是一个分布式网络操作系统，它按照参考设计，以服务的形式交付一组系统资源，并受基于用户指定意图的约束，统称为蓝图（图1）。AOS利用一个强大的分布式状态管理基础设施来实现这些目标。
上面的声明是AOS架构的一个最小但完整的规范，因此相对来说比较枯燥。让我们在数据中心的上下文中添加一些示例，以帮助将上述语句内部化。

意图

意图是对期望结果（服务）的声明性规范，传达了对系统基础设施的协作行为的需求，而不指定规定如何实现它（期望结果）的命令。意图示例如下：
提供到1000台服务器的连接，在边缘使用二级和/或三级访问，核心部分是1:1的超额订阅（无超额订阅），端点（如主机、虚拟机或容器）分组到隔离域（包括通信和地址空间隔离）。有些端点可以通过世界其他地方访问，有些则不可以，策略与控制安全性和负载平衡的隔离域相关，通过至少n个链接连接到世界其他地方，以支持外部流量并防止可能的故障。

参考设计

上一节中的示例意图可以通过使用不同的底层系统基础设施以多种不同的方式得到满足。组成系统资源以交付由意图表示的服务的方式由参考设计决定。
参考设计的一个例子，我们将其识别为RD1，它是：“我将使用基于BGP的三阶段Clos作为我的IP结构。我将在运行BGP的L3连接我的终端服务器。我的工作负载将基于容器。对于每个容器，都会向结构中注入一条主机路由。”
引用设计为其中的元素定义了一组必需的角色。参考设计中的元素是系统（表示虚拟或物理设备，并在下面定义）、链接等。在上面的示例中，设备角色是：leaf、spine、l3_server。链接角色包括spine_leaf、leaf_server、leaf_router、spine_router。要使设备发挥给定的作用，它必须支持特定参考设计指定的一些功能集。需要注意的是，通过api公开了3000个特性的设备可能在只需要一小部分特性的参考设计中发挥作用。同样的角色可以通过一个具有更有限（集中）功能集的设备来实现，只要它符合角色的需求。一个替换单元现在变成一个扮演特定角色的设备，从而将角色从一个确切的硬件（拼图块4）中分离出来。将一个设备更换为另一个能够发挥相同作用的设备的行为不会影响系统的运行，并且可以为操作员的利益而加以利用。
这种方法使可靠性成为整体的函数，而不是它的一个组成部分。替换单元是从扮演非常特定角色的角度来看的系统，而不是从它能够支持的所有功能的角度来看。

参考设计的概念带来以下好处：
•在系统级，它使构建新的参考设计和支持新的用例变得容易。
•在设备层面，考虑到设备在参考设计中扮演着特定的角色，您不必抽象所有设备功能（因为您不需要所有功能）。对一小部分功能的主要支持要比对整个功能集的支持容易得多。
•在设备级别，您不必担心让设备抽象处理所有供应商的任意用例（一些尚未成功完成的事情）。
值得注意的是，在AOS中，参考设计是将功能组合成服务的关键促成因素。这种可组合性在下面进一步描述的服务呈现过程中表示。不需要通常用于管理低级特性的可组合性的高级特定于域的语言。

引用设计RD1规定，整个服务由以下子服务组成（每个子服务的作用域跨越整个系统）：
1、验证布线是否符合预期（这些是参考设计中与链路相关的预期）
2、验证接口是否处于正确的操作状态（例如，使用的接口应为“向上”，其余的应为“向下”）
3、验证是否建立了特定的BGP会话（这些是参考设计中与BGP对等方相关联的期望值）
4、验证设备上的配置是否与预期配置对应
5、验证路由表条目是否与预期一致
6、验证感兴趣的端点是否可以相互ping

这些系统范围内的每个子服务都由在扮演特定角色的系统上运行的相应服务组成。下图演示了数据模型中的典型服务构件，例如数据中心“SF_Pod”。每个服务都与一个或多个期望相关联。每个服务都被检测以收集其状态（与期望相关）。如果未达到预期，则会生成警报。这个模型同样适用于低级服务以及复杂的复合服务。

要说明服务组合，请考虑在蓝图级别，服务显示为特定于功能的服务组件（路由、布线等）的组合，这些组件依次聚合基础架构中的服务组件（路由、跨不同系统的布线）。
在AOS中，设备遥测代理利用设备支持的本机协议收集状态，并将它们与期望值进行比较，如果存在不匹配，则生成异常。

另一个代理通过响应设备遥测代理产生的更改，在设备级别聚合这些状态。另一个代理通过对设备级状态的更改作出反应，聚合设备上的状态。这个基本发布/订阅模式的实例化本质上构成了AOS应用程序。

在设备上运行设备代理时，收集的数据可以尽可能靠近源进行处理，并且可以决定只在网络上传播知识丰富的信息，从而在重要时限制遥测通信量。
请注意，上面项目符号列表中的服务期望可以而且通常可以涵盖与运营商相关的期望（1-5）和与消费者相关的期望（6）。与操作员相关的期望有助于故障排除。与消费者相关的期望有助于确定问题对消费者的影响。因此，AOS不局限于与消费者相关的期望（6），而是让操作员在出现问题时调试系统，它允许专家插入自己的知识并定义诊断（1-5），以立即提醒可能出现的问题。随着有关系统行为的知识的提高，可以插入从新获得的最佳实践中断言的新期望。使用AOS的随叫随到的工程师需要不断提高对系统行为的认识。注意，AOS在特定（实例化）参考系统（拼图块9）的上下文中自动生成和执行这些测试。换句话说，不需要编写脚本和定义执行这些测试的规则，也不需要使它们与当前拓扑保持同步，因为当前拓扑是一个复杂而脆弱的过程。AOS实现这一点是因为它对系统和功能进行了建模，并利用了特定的参考设计。这些模型的实例表示为状态实体，并在“分布式状态管理基础设施”一节中进行了描述。
每个测试都可以被视为测试结果和期望值的配对，当结果与期望值不匹配时（即当检测到异常时）将生成警报。异常包含有助于操作员的可操作数据。例如，对于上面的测试（1），系统X希望看到系统Y是连接到端口Z的链路上的邻居。如果不是这样，则会发出警报，并显示实际（错误）的邻居，或者没有邻居。注意，这个测试依赖于相关设备的某些特性（例如，“spines和leafs必须支持LLDP”）。在设备被批准在特定的参考设计中发挥作用（即被包括在“硬件兼容性列表”中）之前，其功能（就支持的功能而言）将得到验证。
系统的健康状态可以简单地从未完成的警报数中推断出来。从数据中提取知识被构建到系统中（（a）在下图中，拼图块#10）。因此，AOS努力收集更少的数据并提供更多的知识。这种持续的验证过程在通常被称为“Day-2”的操作中是活跃的。
相反，在没有意图和参考设计提供的上下文的情况下，提取该知识通常涉及（下图中的（b）项）：
•“丰富的可视化”帮助专家用户通过一些视觉线索提取知识，通常表示数据是非常原始的
•成本高昂的集成包括编写相关规则、理解数据源的对象模型、将其映射到端到端意图的轶事知识
从本质上说，这意味着，在缺乏从意图中获得的可操作见解的情况下，大数据遥测是对运营费用爆炸的一种邀请，因为需要花费大量资源从数据中提取知识。

然而，AOS在需要和/或必要时（拼图13）能够收集大量信息，这得益于设备代理和AOS状态存储库之间优化的二进制传输，以及处理和压缩尽可能接近源的数据的能力。

约束条件

约束是对系统中变量或参数可能发生的更改的限制。约束允许用户插入适用于其环境的某些限制。例如，他可能只想考虑某种类型的设备（供应商A或B）或容量（具有6x40G端口和48x10G端口的交换机），或IP地址池或VLAN ID的限制。约束本质上有助于根据特定环境对引用设计进行微调。

抽象

关于系统和服务的建模，AOS方法没有多少指导原则：
1、每一个模型都是错误的，只是有些模型在特定情况下比其他模型更有用（拼图1）。
2、配置和状态接口在其固有的复杂性和性能要求方面存在根本区别；因此，它们应该被不同的模型分开和管理（拼图6）。

关于第1点，AOS并不试图定义“硬件抽象层”（HAL），因为这是一项困难的任务，如果不是不可能的话，它会导致固执己见的模型，这些模型要么遭受最小公分母综合症的折磨，要么太复杂而不起作用。建模有两种方式可能出错：第一种是在模型定义时，第二种是在将现实生活中的问题域映射到模型中的类时。继承使这些错误以后很难改正。
在AOS中，对于每个引用设计，都指定了一个声明性规范，说明设备在蓝图的上下文中应该做什么来完成其角色。这些声明性设备规范的生成由AOS服务呈现过程执行，该过程也可供系统管理员检查和扩展。服务呈现生成：
1、声明性配置
2、期望和遥测规范
3、警报定义
关于点2，值得注意的是，配置是一个非常有创意的系统设计过程的接口，必须是灵活的和非固执己见的。这与评估系统的健康状况有着根本的不同。作为一个类比，虽然设计类似人类的机器人或开发人工智能非常复杂，但评估人类健康的过程要结构化和明确得多。
从声明性的设备级规范来看，在AOS中将设备特性组合成配置是用代码（python）完成的，并由系统管理员完全控制（检查/扩展），遵循当前的DevOps最佳实践。但是，AOS生成这些声明性规范，从而使设计人员或系统管理员不必生成数百个文件，并在系统进行更改时保持它们的一致性。这种变更管理由响应性的发布-订阅后端支持，该后端根据各种状态变更更新蓝图。服务呈现的另一个方面是，它生成测试和期望的定义，以验证服务交付。这里，设备接收一组要执行的测试（来自不断增加的受支持测试目录）。反应逻辑检测异常并在测试结果与预期不匹配时生成警报。这种遥测收集由强类型接口支持，因为性能和可预测性在这里至关重要。

分布式状态管理基础设施

AOS使用分布式状态管理基础设施，可以描述为以数据为中心的通信结构，具有弹性和容错的内存数据存储，支持无状态代理的部署/开发，允许代理通过优化的二进制传输协议通过基于发布-订阅的逻辑通信通道进行通信。
上面提到的通信结构意味着系统中的代理之间存在逻辑通信信道。代理通过发布实体和订阅实体中的更改，通过基于属性的接口（因此在前面的描述中以数据为中心）进行通信。以数据为中心还意味着数据定义是框架的一部分，通过定义实体来实现，而不是基于消息的系统。请注意，以数据为中心的发布-订阅系统不会受到基于消息的系统所带来的问题的困扰。也就是说，在基于消息的系统中，消息的数量迟早会超过系统存储或使用它们的容量；处理这一点很困难，因为必须重播消息的历史才能达到一致的状态。另一方面，以数据为中心的系统能够适应状态变化的激增，因为它基本上只依赖于最后一个状态（拼图块4）。这个状态捕获重要的上下文并抽象出导致它的所有可能的（和不相关的）事件序列。使用状态机范例编写的代码更易于阅读、维护和调试。要深入了解此主题，请参见：
数据中心自动化中的分布式系统挑战
硬问题（弹性、容错）代表所有代理一次性解决。然后，典型的体系结构由许多无状态代理组成，这些代理在出现故障时可以重新启动，并通过简单地从sysdb中重新读取它们订阅的状态来从它们停止的位置恢复。

AOS应用解剖

AOS应用程序是上面描述的无状态代理的集合。一般来说，AOS中有三类代理。
 交互代理（Interaction Agents，IA）负责与用户交互，即从sysdb获取用户输入并向用户提供相关状态。
 应用程序代理（AA）负责通过订阅输入实体和生成输出实体来执行特定于应用程序域的转换。
 设备代理（DA）驻留在（或AR代理）被管理的物理或虚拟系统（例如交换机、服务器、防火墙或负载平衡器）上，并用于使用本地（设备特定）接口编写配置和收集遥测。
AOS内置应用程序和自定义应用程序都遵循相同的模式。内置应用程序面向那些希望利用经过验证的最佳实践参考设计实现和可预测性而非可扩展性的用户。另一方面，自定义应用程序，由需要将其专业知识插入AOS的专家用户实现。

可扩展性

AOS是在用户希望从头开始扩展它甚至构建应用程序的前提下构建的。本质上，可扩展性允许用户控制配置生成、遥测收集和警报生成。为了实现这一目标，AOS公开了这些旋钮：
1、蓝图结构可以修改以支持不同的参考设计。
2、角色建模是通过服务呈现过程实现的，其转换本质上是插件模块。
3、AOS支持资源管理，例如，IP地址池由AOS资源池管理，但也公开了设置这些资源的api。
4、用户可以完全控制约束管理。
5、遥测功能目录可以通过插件模块扩展。
虽然本文中的示例集中在数据中心用例上，但是框架中没有特定于数据中心（或特定于网络）的内容。

过程概述

虽然捕获托管基础设施的状态很重要，但捕获服务生命周期过程的状态也同样重要。
蓝图/服务生命周期由4个不同的阶段组成。
1、设计阶段-帮助用户使用给定的约束集制定设计模板。在这种情况下，AOS本质上为设计网络服务提供了一个“计算机辅助设计”（CAD）工具。
•AOS允许“滑动的抽象规模”，用户可以从一个非常高级别的规范（“服务器数量”）开始，让设计过程指导他，并根据指定的约束计算可能的选项，从而生成蓝图。或者，在频谱的另一端，AOS允许对整个蓝图进行明确的规范，例如，包括自定义布线和IP地址分配。UI中所有可用的东西都可以通过api获得。
2、构建阶段-将资源分配给设计模板，生成蓝图。在这种情况下，AOS本质上提供了“计算机辅助制造”（CAM）工具，它使用设计自动化产生的工件来制造网络服务配置和遥测期望。
•用户有权选择哪些资源应由AOS资源池管理，哪些资源将通过显式API调用提供。
3、部署阶段-处理部署所需配置（根据参考设计配置资源）。
4、持续验证阶段-处理生成测试、验证预期、生成警报和遥测。

总结

AOS在供应商不可知的环境中提供了强大的、意图驱动的网络服务自动化，从而提供了消费者的选择并减轻了供应商的锁定。
如前所述，真正的系统复杂性导致70-80%的中断是由于改变配置而不是初始部署。由于AOS中的配置、遥测和期望是以等幂的方式从单一的真实源（用户指定的意图）派生的，所以初始部署和更改管理之间没有区别。“回滚”更改相当于从过去某个期望点重新加载意图。
AOS采用DevOps实践，使用代理为基础结构中的所有系统生成（在代码和模板中）配置。然后，AOS在DevOps实践的基础上构建，消除了可管理性问题，方法是从单一的真实（意图）源生成这些配置，并基于它们所扮演的角色和参考设计。通过这种方法，AOS通过引入期望驱动的服务交付，将数据中心控制提升到了一个新的水平，这将驱动上下文丰富的遥测，并提供简单和知识丰富的警报，以清楚地识别服务和客户影响。这些好处可以用光