Robotron和Ansible如何实现网络可编程和自动化

Posted 2021-04-25 SDNLAB

作者简介：唐昊，现就职于华为，从事云网络研发工作。本文所有观点仅代表作者个人观点，与作者现在或者之前所在的公司无关。

自动化和编排通过简化网络运营和管理，可帮助公司提高业务部署速度，节省大量时间和金钱。本文主要分成两章：

1、介绍Facebook Robotron项目，阐述当前传统网络在IT运营中遇到的瓶颈和挑战，以及Robotron的架构和设计。

2、针对上述所遇到的问题，以Arista公司为例，介绍使用Ansible网络自动化方案（官网介绍）。结合Napalm开源项目，对网络配置管理操作的抽象，屏蔽多厂商差异。对数据中心网络设备及网络服务实现自动化管理和部署。

Facebook Robotron

Facebook从2008年起就已经开始使用Facebook Robotron项目来管理位于全球的数万台网络设备以及相连的数十万服务器。在网络中可能包含多种类型的设备：路由器、交换机、防火墙、负载均衡器、服务器、PC等等，网络工程师要根据客户的需求，对数据网络进行规划、设计，并对网络设备进行配置调试最终将网络方案落地。在实际部署和管理网络时，会有以下几个痛点：

• Vendor Differences：在数据中心里很有可能存在不同厂商的设备，每个厂家设备的硬件以及运行的操作系统都不相同。网络管理员需要懂得如何使用特有的命令以及API进行调用，这对管理一个大型网络来说，是十分复杂和繁琐的事情。

• Versioning: 网络拓扑、路由、设备的版本以及配置会随着时间的推移，进行不断的变化。这要求工程师需要懂得如何同时管理多个不同“版本”的网络。

• Multiple Domains: 一个大型网络中包含不同的网络域，存在“网络中的网络”。例如Facebook网络中包含接入点、骨干网络和多个数据中心。这些网络里面的设备、网络拓扑以及功能职责各不相同。必须所有的配置正确才能保证整个网络的功能正常。

• Dependency: 修改一台设备的网络配置很有可能影响到网络中其他设备的配置。例如，新增加了一台路由到自治域中，意味着其他路由的配置也要进行了改变。这种依赖性对网络工程师是很难处理的。

  
  

针对这些挑战，Facebook设计了Robotron网络运维项目，用于管理大型的DC网络。主要目标有以下三点：

• Configuration-as-code: 尽量减少人工干预，通过使用配置模板（templates）生成对应的设备配置，从而提高了使用重复率，并且减少了配置出错的可能（比如不小心写错命令，导致语法出错）。

• Validation: 采用了几种验证机制用于避免配置出错。其中包括：人为检查、通过监控动态网络状态和配置等等。

• Extensibility: 可扩展性。面向设备，提供功能完整的、厂商无关的网络建模接口，这使网络管理员不再需要关心不同厂商设备的差异化。

架构

网络管理系统采用“自顶向下“的方式进行抽象，一共分为四个阶段，网络设计（Network Design）、配置生成（Config Generation）、配置下发（Deployment）和网络监控（Monitoring）。

网络设计

第一阶段，从high-level的网络设计意图转成FBNet对象，其中包含着具体数据信息（Value）以及对象之间的关系（relationship）。对象(object)是一个抽象类，定义了被管理或被作用的对象，在不同层次中可以被继承或者扩展。下图展示了集群cluster里的设备信息（例如厂商、设备数量）和网络拓扑（设备之间是如何连接的）。根据这些信息，将构建生成多个FBNet对象模型（下图显示了一共生成了94个对象，7个类型的模型，100多个相互关系）。利用抽象出的网络对象模型，实现对网络资源分配。

那么Robotron是如何保证在网络设计这一步骤中不出任何差错的呢？例如在模板中的拓扑缺少了信息或者分配重复的结点等错误。这主要有两种方法避免发生错误，分为自动和手动模式。

• 系统嵌入了自动验证对象object的合法性。当从模板template转译到设备对象object时，这些规则会去检查描述设备的信息（value）和相互之间的关系（relationship）是否正确。

• 系统会在生成FBNet对象前，向用户展示该设计对网络产生的变化。用户可以对其进行检查。

• 系统会记录所有的网络设计变更日志，用于跟踪错误和Bug。同时还记录了管理员的ID，可以通过ID查找到这个管理员对网络设计变更的历史记录。

配置生成

这一阶段是从FBNet对象生成对应厂商的设备配置。不同厂商所对应的设备配置语法会不同，Robotron把设备配置分为两部分：

• 静态的，厂商相关的模板。（例如带有特殊的语法关键词）

如下图所示，Robotron获取到所有相关的FBNet对象模型，并且从中获取对象信息存入Thrift对象中。最后结合Thrift对象和厂商相关的模板生成对应的设备配置。

Robotron使用了多种方法用于保证配置的正确性：

• 系统会存储设备的配置和模板在Configerator里（版本管理仓库），所有的更改记录都能被查看到，并且能够进行单元测试。

• 系统会备份所有设备当前运行的配置，当出现紧急情况（例如发生灾难）时，可用于快速恢复网络。

• 系统监控当前设备配置变化，当发生违背意图的配置时，会进行警告通知用户。

网络部署

数据中心在进行服务器部署时，往往上线一批就要数百上千、甚至上万台，数量非常庞大。如果需要通过手工方式对每一台进行系统升级、下发配置是非常耗时的，也要消耗很多的人力资源。于是出现了一些自动化部署的方案，在不需要网络管理员亲自到现场对设备进行配置的情况下，实现设备上电后即可自动完成部署。在上线后，随着时间的推移，业务需求可能会发生不断改变，对网络性能要求也不断提高，设备的配置也要不断的更新。相比传统的人工部署方式（CLI），自动化网络部署方式不仅提高了部署效率、节约了人力成本，还可以有效地避免配置错误。

Robotron可以分为两种不同的网络部署方式：

• Initial Provisioning：Robotron会清除旧的配置并且复制新的经过验证的配置到设备上。这种方式属于全替代（replace），相比增量式的（直接把新的配置merge到原配置上）更不容易出错。因为每个设备处在全新的状态（clean state）。

• Incremental Updates：增量式的更新配置，为了降低对正在运行的设备造成的影响，Robotron采用了以下几种机制：

• Dryrun Mode：用户可以在部署前后，查看下发的配置和设备里正在运行的配置，进行对比（diff），并且可以检查出一些异常和错误配置。

• Atomic Mode：所有的操作应该是原子化的。这是因为通常部署的时候会向多台设备下发配置进行更新，如果在部署期间出现任何错误，应该立马恢复到之前的运行配置。

• Phased Mode：部署的时候可以分阶段进行。这是因为设备之间联系紧密, 并且存在故障扩散现象。例如下发防火墙规则的时候，通常要求工程师将新的配置分成几个阶段步骤进行下发。Robotron会监控跟踪任务进展，如果中间某一阶段部署失败了，就不会继续进行下去了。

• Human Confirmation：当部署成功后，工程师可以根据这一段时间内当前网络是否与理想的网络相同，进行最终的确认，否则Robotron会进行回滚。

网络监控

网络的基础监控通过各类接口和协议，通过使用主动和被动监控技术来监控服务器健康状态，以便及时、准确地了解网络中实际的运行状态。 Robotron监控有三种机制：

• Passive Monitoring：被动监控检测一些事件，例如：设备配置更新、路由翻动（route flapping）、设备重启事件等等。其中Syslog监测就是是基于被动式的，针对监控到的日志信息，并且结合正则表达式匹配灵活过滤出关键信息，以便于配置trigger，在发现异常日志信息时触发告警通知。

• Active Monitoring：主动式的监控，进行性能采集（例如CPU、内存使用情况）和监测设备状态（用于生成FBNet Derived模型）。下图描述了主动式的监控分为三个部分：任务管理器（Job Manager）、引擎（Engines）、后端（Backends）。

• Job Manager 用于管理和分发监控任务，每个任务涉及到采集间隔时间、采集的数据类型、存储到哪一个后端等等。

• Engines 接收到任务后，会通过各类接口和协议从对应的设备上采集数据。

• Backends 会把采集到的数据转换成相应的格式储存起来。

• Config Monitoring：Robotron同时使用主动和被动监控技术监控当前设备上运行的配置。当有配置更新时，被动监控检测会检测到新生成syslog日志，然后触发trigger下发一个主动式的任务（job）用于采集设备当前配置。每次采集到的配置会备份到版本管理仓库中，用于跟踪每个设备中的配置历史更新情况。

Ansible自动化管理和部署网络

今年NANOG大会上有个演讲Network Automation: Do I Need Expensive Tools To Do Meaningful Automation提起了如何去自动化管理网络的步骤。从管理网络设备到整个网络服务到阶段，需要一步一步完成，不能一下子跨越。公司需要构建DevOps文化，需要搞清楚当前自动化运维处于什么阶段，分清楚不同组织的角色，这样才能互相配合，从而实现自动化运维和开发。

下面会介绍演讲中提到的自动化开源工具Ansible。目前Ansible、SaltStack、Puppet、Chef都是比较受用户欢迎的自动化化运维工具，其中Ansible和SaltStack使用python编写，具有良好的可移植性。Ansible使用和部署简单（no databases，no daemons，no agents），控制节点上编译执行代码，然后通过SSH或者其他协议的方式将其命令发送至目标网络设备上执行。例如思科、Arista等公司的设备都支持Ansible模块去管理网络。

网络可编程不在于各种接口和各种规范，而在于对于网络的抽象。Ansible可以把对象的参数定义和执行层面进行解耦，从而实现定义一次，执行多次的效果。如下图所示：

Arista+Ansible

大概在2014年中旬的时候，Arista就已经开始使用Ansible去批量管理和部署网络设备了。以配置vlan和interface为例子，看看是如何建立数据模型的。

最上方标出的红框是Arista对vlan进行配置的命令。右边是抽象出vlan对象，属性有vlanid和name，这种字典式的模型是用YAML所描述的。同理，对于Ethernet interface有三个属性，分别是name, description和address。这样抽象有个好处，不仅可读性高，而且可以屏蔽厂商设备差异化。

根据数据模型，我们可以创建出Jinja template。如下图所示（vlan和interface所对应的模板）：

那么如何使用这些模板（template）呢，前面提到过Ansible具有很强大的编排能力，可以使用playbook把角色（role），任务（task），inventory串起来。自动化和编排通过简化网络运营和管理，帮助实现这种敏捷性。无论是对单个设备还是服务进行管理或部署，网络运维人员需要使用模板编排，并且可以像代码一样进行版本控制、复制、更新模板。通过模板描述多个网络资源的依赖关系、配置等，并自动完成所有配置，以达到自动化部署、运维等目的。

如果不使用模板的形式，这会增加了开发人员和运维人员的沟通成本，而且当遇到问题时，运维人员或者QA对整个服务里面的实现逻辑并不了解。但如果使用模板去实现服务的话，网络运维人员可以根据不同设备及服务自行组装编排部署，可以填写参数。开发人员只需要保证对每个模块/任务功能正常即可。例如Ansible Playbook以YAML语言进行对任务、角色等进行编排，可读性高，能够跨越不同组织部门对其操作。

下图为利用Ansible Playbook对网络设备Vlan和Interface进行编排部署：

• hosts file: 指定inventory，把目标设备放进来。在实际项目中可以通过自动化资产扫描从而实现动态的添加设备。

• 由于对两个设备vlan的配置相同，所以把vlan对象放到全局变量文件中group_vars对于差异性的配置模板放到host_vars中。

• 运行playbook文件，会根据任务中的对应的模板生成配置进行下发，每个任务具有幂等性。

把运维一系列的手动执行的操作，用脚本串起来的思路做成工具去部署网络设备，做不到幂等性。在管理或部署网络设备时，一个请求除了成功和失败两种状态，还存在着超时状态。所以需要将对网络设备的操作设计为具有幂等性 ，即执行多次的结果与执行一次的结果相同。如果使用这种方式，当出现超时的时候，可以不断地重新请求直到成功。例如修改网络设备运行中的配置时，可能存在当前配置状态已经是理想的了，此时如果通过cli继续下发命令，有些命令操作会报错。正确的做法是实现所有function或者module对外接口实现幂等性。如下图所示，是Arista公司对部署设备配置时的方案，运行playbook文件，eos_config module首先会收集设备正在运行的配置，然后进行对比。如果目标设备已经处于目标状态中，该配置命令就不会被执行，从而实现了幂等性。

Ansible+Napalm

使用Vagrant和VirtualBox工具模拟网络设备环境，可以参考这篇博客和Setting up the lab教程去搭建环境（思科和Arista的设备镜像需要到官网上注册后才能下载）。

管理Inventory，例如需要管理两个DC。推荐的结构如下：

使用ansible-playbook命令时可以带上-I参数指定执行哪一个inventory。host_vars目录里可以用inventory_hostname文件名描述一个设备变量（例如switch1.yml）或者用inventory_hostname目录里面包含多个变量文件（例如vlans.yml可以用于描述交换机vlan信息）。host_vars变量只能用于当前的设备使用，group_vars是本group的都可以使用。使用YAML格式是因为可读性高（json文件也是可以的）。如果host_vars中和group_vars中有相同变量，则以host_vars中的为准。template模板放在role目录下面。运行playbook后，变量会被加载到指定厂商的模板中，生成配置文件。下图展示了使用Ansible生成每个设备配置的框架图。

部署网络可以分成以下步骤：

Design：对整个网络建数据模型，生成对应的设备数据模型。

Transformation：通过JINJA2模板转译成对应的设备配置。

Deploy：使用Ansible对应厂商开发的module或者通过Napalm工具下发配置到设备上。

Retrieve facts: 获取设备当前状态。

Validate：导入一个Data Model去验证网络设备状态是否和理想的一致。

NAPALM实现了对网络配置管理操作的抽象，屏蔽多厂商差异，并且可支持和集成到自定义脚本例如Ansible，实现自动化处理。下面是常用的Napalm模块：

• napalm_get_facts：用于获取设备信息，返回统一的数据结构。

• napalm_install_config：下发配置到设备中。

validate.yml：

playbook：

Note

对于正在向NetDevOps转型的公司，之前并没有使用模板的方式进行网络设备的部署，导致对当前设备数据模型变量的缺失。我在Github上找到一个开源项目netcopa，可以解析对应的厂商网络设备配置，生成数据模型。例如：

配置文件：

执行后，生成对应的Data model：

Reference：

• Network Programmability and Automation：强烈推荐，今年刚出版。可以在 www.safaribooksonline.com 网站上注册一个账号即可免费阅读。

• Network Programmability and Automation

• Ansible network automation:

• https://www.youtube.com/watch?v=7FphWEFQbac

• https://www.youtube.com/watch?v=VYEVjKvMKqU

• https://www.youtube.com/watch?v=OVjOr1TaVf8&list=WL&index=2&t=0s

• https://www.youtube.com/watch?v=pI1NZrkIk_o&list=WL&index=3&t=0s

• https://www.youtube.com/watch?v=k1SeuzeT9gg&list=WL&index=4&t=0s

• Cisco:

• https://pynet.twb-tech.com/blog/automation/cisco-ios.html

• http://www.cisco.com/c/en/us/support/switches/nexus-7000-series-switches/products-command-reference-list.html

• Juniper:

• https://www.juniper.net/documentation/en_US/junos15.1/topics/concept/junos-script-automation-overview.html

• http://www.juniper.net/techpubs/software/junos-security/junos-security10.4/junos-security-cli-reference/junos-security-cli-reference.pdf

• Arista:

• https://eos.arista.com/arista-ansible-getting-started/

• https://www.arista.com/en/products/eos/automation

• https://www.arista.com/docs/Manuals/ConfigGuide.pdf