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

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

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

1、介绍Facebook Robotron项目,阐述当前传统网络在IT运营中遇到的瓶颈和挑战,以及Robotron的架构和设计。
2、针对上述所遇到的问题,以Arista公司为例,介绍使用Ansible网络自动化方案(官网介绍)。结合Napalm开源项目,对网络配置管理操作的抽象,屏蔽多厂商差异。对数据中心网络设备及网络服务实现自动化管理和部署。

Facebook Robotron

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

  • Vendor Differences:在数据中心里很有可能存在不同厂商的设备,每个厂家设备的硬件以及运行的操作系统都不相同。网络管理员需要懂得如何使用特有的命令以及API进行调用,这对管理一个大型网络来说,是十分复杂和繁琐的事情。
  • Versioning: 网络拓扑、路由、设备的版本以及配置会随着时间的推移,进行不断的变化。这要求工程师需要懂得如何同时管理多个不同“版本”的网络。
  • Distributed Configurations:从高级意图到生成许多设备的配置,是十分复杂和容易出错的。例如迁移一台路由,其中涉及到IP地址、路由表、接口等等一系列的变化。
  • Multiple Domains: 一个大型网络中包含不同的网络域,存在“网络中的网络”。例如Facebook网络中包含接入点、骨干网络和多个数据中心。这些网络里面的设备、网络拓扑以及功能职责各不相同。必须所有的配置正确才能保证整个网络的功能正常。
  • Dependency: 修改一台设备的网络配置很有可能影响到网络中其他设备的配置。例如,新增加了一台路由到自治域中,意味着其他路由的配置也要进行了改变。这种依赖性对网络工程师是很难处理的。

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

  • Configuration-as-code: 尽量减少人工干预,通过使用配置模板(templates)生成对应的设备配置,从而提高了使用重复率,并且减少了配置出错的可能(比如不小心写错命令,导致语法出错)。
  • Validation: 采用了几种验证机制用于避免配置出错。其中包括:人为检查、通过监控动态网络状态和配置等等。
  • Extensibility: 可扩展性。面向设备,提供功能完整的、厂商无关的网络建模接口,这使网络管理员不再需要关心不同厂商设备的差异化。

架构

下图展示了Robotron的架构,其中FBNet作为底层基础,用于描述和储存网络设备模型对象。FBNet由两部分组成,抽象出了物理相关的描述(例如设备,接口等)和逻辑部分(例如BGP协议、IP地址)。另外FBNet模型可以分成理想(desired)和现实推导(derived)的两种。理想的模型是用户或者网络管理员所想描述的理想网络状态,而实际推导出的模型反映的是当前网络状态。通过互相比较,可以找出网络的异常,例如配置错误等等。

网络管理系统采用“自顶向下“的方式进行抽象,一共分为四个阶段,网络设计(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把设备配置分为两部分:

  • 动态的,厂商无关的信息(例如设备的sysname、IP地址)。无论哪一个厂商设备,都是需要这些信息,而这些信息是由用户或者网络管理员来决定的。
  • 静态的,厂商相关的模板。(例如带有特殊的语法关键词)

如下图所示,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生成每个设备配置的框架图。

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

  1. Design:对整个网络建数据模型,生成对应的设备数据模型。
  2. Transformation:通过JINJA2模板转译成对应的设备配置。
  3. Deploy:使用Ansible对应厂商开发的module或者通过Napalm工具下发配置到设备上。
  4. Retrieve facts: 获取设备当前状态。
  5. Validate:导入一个Data Model去验证网络设备状态是否和理想的一致。

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

  • napalm_get_facts:用于获取设备信息,返回统一的数据结构。
  • napalm_install_config:下发配置到设备中。
  • napalm_validate:验证设备状态。不需要对设备的所有信息进行验证,只需要指出验证某一项的状态信息。例如通过get_interfaces_ip函数可以去验证某个端口的IP地址是否与理想的一致。另外还可以使用条件语句去判断参数是否符合理想状态的要求。例如判断cpu使用率是否小于15%。validate.yml:

    playbook:

Note

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

配置文件:

执行后,生成对应的Data model:

Reference:


  • 本站原创文章仅代表作者观点,不代表SDNLAB立场。所有原创内容版权均属SDNLAB,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用,转载须注明来自 SDNLAB并附上本文链接。 本站中所有编译类文章仅用于学习和交流目的,编译工作遵照 CC 协议,如果有侵犯到您权益的地方,请及时联系我们。
  • 本文链接https://www.sdnlab.com/20798.html
分享到:
相关文章
条评论

登录后才可以评论

thddaniel 发表于18-05-14
0