作者简介:唐昊,现就职于华为,从事云网络研发工作。本文所有观点仅代表作者个人观点,与作者现在或者之前所在的公司无关。
自动化和编排通过简化网络运营和管理,可帮助公司提高业务部署速度,节省大量时间和金钱。本文主要分成两章:
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 会把采集到的数据转换成相应的格式储存起来。
- Job Manager 用于管理和分发监控任务,每个任务涉及到采集间隔时间、采集的数据类型、存储到哪一个后端等等。
- 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的设备镜像需要到官网上注册后才能下载)。
1 2 3 4 5 6 7 8 9 10 11 12 13 |
$ git clone https://github.com/ios-xr/iosxrv-x64-vbox.git $ brew install socat $ git clone https://github.com/JNPRAutomate/vagrant-junos.git $ vagrant plugin install vagrant-junos $ vagrant up # the most common and preferred way of installation $ sudo pip install ansible # install NAPALM $ pip install napalm $ pip install napalm-ansible .... |
管理Inventory,例如需要管理两个DC。推荐的结构如下:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 |
. ├── ansible.cfg ├── inventory/ # Parent directory for our environment-specific directories │ │ │ ├── DC1/ # Contains all files specific to Data Center 1 │ │ ├── host_vars/ # device specific vars files │ │ │ ├── router1 │ │ │ │ ├── interfaces.yml # Device specific interface config │ │ │ │ └── ospf.yml # Device specific OSPF config │ │ │ └── switch1 │ │ │ ├── interfaces.yml # Device specific interface config │ │ │ └── vlans.yml # Device specific vlan config │ │ │ │ │ ├── group_vars/ # group specific vars files │ │ │ ├── all │ │ │ │ └── vlans.yml # Global VLAN config │ │ │ ├── routers │ │ │ │ └── ospf.yml # Global OSPF config │ │ │ └── switches │ │ │ └── stp.yml # Global STP config │ │ └── hosts # Contains only the hosts in the dev environment │ │ │ └── DC2/ # Contains all files specific to Data Center 1 │ ├── host_vars/ # device specific vars files │ │ ├── router1 │ │ │ ├── interfaces.yml # Device specific interface config │ │ │ └── ospf.yml # Device specific OSPF config │ │ └── switch1 │ │ ├── interfaces.yml # Device specific interface config │ │ └── vlans.yml # Device specific vlan config │ │ │ ├── group_vars/ # group specific vars files │ │ ├── all │ │ │ └── vlans.yml # Global VLAN config │ │ ├── routers │ │ │ └── ospf.yml # Global OSPF config │ │ └── switches │ │ └── stp.yml # Global STP config │ └── hosts # Contains only the hosts in the dev environment │ ├── playbook.yml │ └── roles/ # Parent directory for our environment-specific directories │ ├── common |
使用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:用于获取设备信息,返回统一的数据结构。
1234567891011- name: get facts from devicenapalm_get_facts:hostname={{ inventory_hostname }}username={{ user }}dev_os={{ os }}password={{ passwd }}filter='facts,interfaces,bgp_neighbors'register: result- name: print datadebug: var=result - napalm_install_config:下发配置到设备中。
1234567891011121314- assemble:src=../compiled/{{ inventory_hostname }}/dest=../compiled/{{ inventory_hostname }}/running.conf- napalm_install_config:hostname={{ inventory_hostname }}username={{ user }}dev_os={{ os }}password={{ passwd }}config_file=../compiled/{{ inventory_hostname }}/running.confcommit_changes={{ commit_changes }}replace_config={{ replace_config }}get_diffs=Truediff_file=../compiled/{{ inventory_hostname }}/diff - napalm_validate:验证设备状态。不需要对设备的所有信息进行验证,只需要指出验证某一项的状态信息。例如通过
get_interfaces_ip
函数可以去验证某个端口的IP地址是否与理想的一致。另外还可以使用条件语句去判断参数是否符合理想状态的要求。例如判断cpu使用率是否小于15%。validate.yml:
1234567891011121314- get_facts:os_version: 4.17- get_interfaces_ip:Management1:ipv4:10.0.2.14:prefix_length: 24_mode: strict- get_environment:memory:used_ram: '<15.0'cpu:0/RP0/CPU0'%usage': '<15.0'
playbook:
1234567- name: GET VALIDATION REPORTnapalm_validate:username: "{{ un }}"password: "{{ pwd }}"hostname: "{{ inventory_hostname }}"dev_os: "{{ dev_os }}"validation_file: validate.yml
Note
对于正在向NetDevOps转型的公司,之前并没有使用模板的方式进行网络设备的部署,导致对当前设备数据模型变量的缺失。我在Github上找到一个开源项目netcopa,可以解析对应的厂商网络设备配置,生成数据模型。例如:
配置文件:
1 2 3 4 5 6 7 8 9 10 |
! interface GigabitEthernet1/3 switchport access vlan 267 switchport mode access switchport voice vlan 867 spanning-tree portfast spanning-tree bpduguard enable service-policy input company-user-access-450x service-policy output company-user-access-dbl ! |
执行后,生成对应的Data model:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
interfaces: GigabitEthernet1/3: name: GigabitEthernet1/3 service_policies: - direction: input name: company-user-access-450x - direction: output name: company-user-access-dbl spanning-tree: bpduguard: true portfast: true switchport: access: vlan: 267 mode: - access voice: vlan: 867 |
Reference:
- Network Programmability and Automation:强烈推荐,今年刚出版。可以在 www.safaribooksonline.com 网站上注册一个账号即可免费阅读。
- Network Programmability and Automation
- Ansible network automation:
- Cisco:
- Juniper:
- Arista: