SDN实战团分享(十四):网络设备自动化遇到的问题与思考

【编者的话】本文系SDN实战团微信群组织的线上技术分享整理而成,本次由京东金融网络架构师余欣给我们带来网络设备自动化遇到的问题与思考的分享。

嘉宾介绍
--------------------------------------------------------------------------

余欣,京东金融网络架构师,在传统物理网络中瞎混了16年的老网工。
--------------------------------------------------------------------------
分享正文
我一直是做网络的,而且是大家常说的物理网工。 干了16年。虽然,刚刚毕业哪会干了几年的DBA 和SA 的工作。后来就一直在做网络。 企业网,城域网,骨干网都算是参与过。现在SDN 多了。网络设备类型也多了。为了避免引起歧义。我先简单把网络设备做一个范围的限定。 我下面说的网络主要是: 硬件交换机、硬件路由器、防火墙、以及负载均衡等可以被网管的商用设备,并且大量是采用闭源的系统的。这些设备也是传统的物理网工经常遇到的设备形态。另外,我也缩小一下自动化的范围。我下面说的自动化指批量的基于一定流程和场景的管理网络设备。

自动化是一个老生常谈的问题了。我刚刚接触网络的时候,大家就想做一些自动化的工作。 我自己是一个懒人。所以特别想有自动化的工具帮我干活。但是,长久以来一直感觉都做的不太好。我了解到的:BAT 也好,国内的SP 也好都不能算是很完善。不过,这几年来,我越来越觉得自动化需求在扩大。大家越来越想要自动化。
现在流行自动化,我理解有三个方面:

  • 1. 驱动力
  • 2. 软件硬件的开源化
  • 3. 硬件越来越便宜,且同质化

1. 驱动力。云计算已经火了好几年了,虚拟机,云应用自动化的水平越来越高。网络自动化慢慢成为瓶颈。

2.软件硬件的开源化的越来越多了。有很多开源的代码可以用,程序员也有很多,特别在OTT公司程序员很多。

3.硬件越来越便宜,并且同质化越来越厉害。 硬件便宜了,每个人管理的设备就必然多了。以前,运营商几台核心路由器要花上亿RMB。 可以专门找人来人工管理。 现在越来越便宜,且设备也越来越多。自动化需求就越来越强烈。

我自己一直在做自动化的一些尝试。
我把我遇到的一些问题,和大家吐槽一下。我分4 点来说:
1.网络工程师自己的问题。
网络工程师不像SA(系统管理员) PE(产品工程师) DBA(数据库管理员) 哪样。他们天生就是半个程序员,或者说本来就是程序员,传统的网络工程师大部分都是看手册操作设备的,网络设备上都有命令的提示。而且,大量的网络工程师都是从cisco 的CCNA CCNP CCIE 这样学过来的。我自己也是。现在我想想,这些认证考试,还有这些书,从某种意义上说,害了网络工程师。导致现在大量的网络工程师只会敲命令。如果要做批量配置,很多还是拿excel 或者是ultraedit这样的文本工具在做。这个就是网络工程师自己的问题。而且,大量的网络工程师觉得程序不靠谱。因为出了问题不知道怎么查。

2.程序员的问题。
做自动化也好,做SDN也好 都需要大量的代码。就需要程序员。但是,我在阿里在京东金融。接触到的程序员大部分不了解网络。我遇到过给程序员讲2个小时什么是VLAN什么是二层网络。这个也许是特例,不知道有没有人也遇到过类似的问题。还有,懂一些网络的程序员。不太愿意做网络设备的自动化脚本。他们觉得,这个只是个script,不是程序。对自己以后没有什么意义,而且,他们大量的时间和工作花费在了做多厂家的适配的问题,和文本解析的过程中。每天都是体力活。出了问题又被网络工程师说。

3.厂家
现在网络设备基本上每个厂家的设备命令和输出的格式都不一样,甚至升级版本后有变的情况也很多。而且,网络设备厂家以前非常的不愿意做一些好用的接口。现在接口是多了,netconf也好restful也好这些API慢慢多了。关于接口的问题,后面还会说到。其实,大量的厂家的这个接口是很不好用的。

4.有人会觉得现在不是有很多自动化的工具么。
比如puppet ansible chef fabric salt 等等。这些开源的工具是不是可以用?前段时间在群里面也有讨论过。我想说得是这些工具基本都是针对 linux unix 还有windows 等操作系统开发的。对网络设备的支持基本都是刚刚开始起步,比如huawei现在在做puppet的agent。在ansible的galaxy库里面有很多厂家的plugin,那么这些是不是都可以用呢?其实,大家可以去试试看也会遇到一些问题。拿ansible举例来说,ansible有playbook里面定义了很多task,但是你会发现,每个厂家的playbook里面定义的字段都是不一样的。那是不是又回到了原来的问题,使用者要去对每个厂家去熟悉这些东西,自己还是要开发中间的适配层的。不过有进步,因为这些需要适配的东西是格式化的文本。ansible的playbook是基于yaml的。yaml可以直接变成python里面的dict,如果做http的api,直接可以是json的格式,这个确实是减少了很多程序员的工作,但是不幸的是支持的厂家不多。并且,厂家支持的ansible的plug-in不是能干所有的事情,juniper的ansible的plug-in基本就只能装个junos,reboot这些非常简单地东西。这些plug-in还不如没有呢,谁天天升级系统啊还有就是在说说netconf和restful的api,国内的厂家netconf 基本就只有一个壳,里面大量的东西是没有完成或者只做了几个平台的产品。厂家说,他们还没有那么多的时间来开发里面的东西。就变成了,我要管什么内容,拿什么数据或者是改什么内容,都要让他们现做,然后升级设备os。对于网络设备,升级是一个天大的事情(不是所有功能都能用热补丁来完成)。当然,厂家越来越多的支持netconf restful是好事情。我们不应该打击他们,需要一些时间来完善。所以,现在我自己做自动化的时候 基本还是以cli模拟登陆为主,如果有其他api也用。

前面说网络工程师的问题,漏了一个内容。其实和厂家完善api相关,国内的网络工程师很少写HLD和LLD,好一些的公司会有HLD,但是LLD都基本没有,或者非常的不完善。

HLD(high level design)LLD(low level design)这点国外比国内做的好很多。其实没有这些文档,让很多厂家不知道要先做什么后做什么。2006年在ISP做过一个项目,4个人写了10个月的文档,文档加起来有1个多G,但是不写这些东西,怎么让程序员给大家开发工具。其实我在想现在大量的建设IDC,有很多网工说不是就是哪几个套路么。所以,网络工程们有时间是不是也可以做一些开源的IDC的设计文本。我理解openflow其实干了类似的事情,把厂家原来都有的私有的流表开源了,让所有的人都可以来做switch or router这些网路设备。

刚刚说到 API,对于API有什么样的要求? 什么样的API 会好用一些?我从4个方面来看。当然,我并不是说 API 必须要有下面的4 个方面的要求,只是想说有会比较好。

1.数据的结构化。
这个除了cli 的方式外,netconf restful的接口通常都是结构化的数据了,所以,有结构化的数据 开发就舒服很多。

2.连接的无状态性。这一点也许名字叫得不是很合适。
这个问题,在cli 里面是很头疼的问题,现在的网络设备基本都是交互式的。交互式会带来很多问题,比如,程序很难做并发和异步。而自动化因为要管理大量的设备,所以是需要并发和异步的。这里岔开一个小话题。有人说,做自动化用python这些语言行吗? python ruby 这样的脚本语言执行效率很低的。网络交互多的程序,其实大量的时间是消耗在网络传输中的。比如说一台设备和另外一台设备有网络交互来回通常都要超过 1ms(两边都要过协议栈,还有网络本身的延迟),1ms 对与python 来说 也可以干很多事情了。所以,网络的程序,很多时候是在等回来的数据,这个问题就需要并行来解决。

3.下一个是幂等性问题,这个概念是数学的概念。
在http 1.1的版本里面被提到,在restful里面也被提到。如果,我们自己要在网络设备上开发一个agent,哪么这个问题也需要考虑。

4.最后一个是事务性
前面三个问题或者说属性,对于现在netconf 的方式,http +json 或者叫restful 的方式 都不是大问题,基本是能解决的,或者是已经解决的不错的。但是最后一个问题我看到的厂家做出来的api很少有考虑和解决的,我认为这个是一个大问题。没有这个特性不管是什么API到后来都会觉得不好用。对程序员来说最好的是只关心一个初始态和一个终结态,至于中间的过程,不要去考虑顺序,不要去考虑过程。其实,大家看看puppet的思路就是这样的。由于和huawei 交流过puppet agent 的内容。所以和他们讨论过。最后的结论是:如果全部实现很困难。目前能实现的是:我们给他们一些场景,他们基于这些场景在agent 上做一些实现。那么问题又回去了,前面说的LLD又来了。那么如果一个API不能实现上面的4个特性,并且现在的api 还不能做 100% 的工作, 就只能回到 cli 来了。关于自动化的内容,除了设备的视角,还有其他的。比方说自动化前公司的cmdb是不是完善的。其实,很多公司都在做cmdb。但是,经常遇到的问题是,用了一段时间后cmdb 的脏数据越来越多,然后就开始清理数据,甚至是重构流程以及代码。

这个是ITIL相关的图(ITIL 的核心模块图不是这样的)。但是这个图说明了cmdb很重要。
无论是对传统设备的自动化实现,还是其他SDN的实现,如果CMDB做不好,一切都是白费功夫。

最后,我再讲讲我自己是怎么从0 开始做自动化的吧。基于前面向大家吐槽了很多自动化遇到的问题和我自己的一些粗浅的想法。所以,我在现在的公司基本是以cli 的方式为主。如果有好用的api 也用。如果 设备可以支持python。那么我就尝试在上面自己做个agent,原来,这里网络的工作基本是人登录设备干,怎么做第一步的自动化呢。

第一步,做设备的配置备份。大家会觉得这个多简单啊,随便找个程序员就能干了。第一步要解决的问题是:
1. 能够让程序登录到所有的设备,这些设备会是多厂家的。在我们这里有 7 个厂家 (我真是要哭了)并且有的厂家产品型号不一样,命令也有差别。举个例子,cisco的29xx系列的交换机和nexus 7K的交换机命令就不完全一样。
2.通过登陆设备的取配置,把软件的基本框架建好。
3.保留所有设备的配置,后面可以用。
这里多提一句,自动化不是目的。目的是,你每做一步,你能留下什么数据。不要看不起数据,数据多了它会有用的。

第二步:我开始做配置审计
在第一步里面基本都是程序员干的活。网络工程师要配合的是,把所有的拿配置的命令告诉程序员。配置审计我换了一个思路,是不是可以把程序员的一些工作和网络工程师的工作分开。配置审计需要明白配置是什么意思,或者是配置里面有什么内容开能干。那么程序员不见得都看得明白这些配置,如果要审计一个配置就要改代码,那程序员没法活了。所以,我借鉴了ansible里面的playbook的方式,用了jinja2的做为模板。然后网络工程师写模板,网络工程师只需要知道简单地 jinja2模板的编写,及一些简单地正则表达式就可以了。另外,程序开发的时候,我对cisco style的配置做了简单地格式化出来,可以让我很容易的获取其中的一段配置。比如我要ospf的配置,那么可以把接口下和ospf相关的以及在router ospf下的所有配置单独拿出来。

好了,今天的分享结束了。

Q&A

Q1:你们用的啥ssh lib?
paramiko本来想用的, 感觉没有expect方便。因为和服务器不一样,pexpect简单多了,并且可以完成与设备的交互式操作。

Q2:到底这种基于netconf restful结构化的北向接口,比适配厂家的独立的北向api或者cli,优势在哪里呢?
因为netconf和restful的数据基本都是结构化的。比cli方便。但是现在厂家的netconf or restful接口功能不是很全。

Q3:有个问题Juniper的设备是能做到幂等性的?可以通过本地拼接成XML通过netconf做配置吗
Juniper是可以的。Juniper的API我说的4个特性都有

Q4:F5可以管理么?
F5可以啊。F5我现在是登陆到tmsh然后run util bash直接进去linux shell了。F5可以在linux shell里面调用tmsh -c "xxxxxxx",所有命令都可以执行。

Q5:一般都有前三个,第四个有的比较稀有,你们现在光是从设备取configure写到cmdb么? 不下配置么?
没有第4个会越来越痛苦的,要不就自己写代码的时候想清楚了。现在可以下配置啊。因为,我能取配置回来。说明我能登陆了。

Q6:expect的话,配置成功失败怎么判定的?如果失败了可以自动回滚吗?
现在基本没有好办法。写上去写慢一点,等一条命令执行完后再执行下一跳。然后做完后把配置取回来。 用配置审计在跑一边。如果符合配置审计的规则就 OK。

Q7:能否举个不是幂等性的场景,想了下觉得大部分场景应该都是满足的吧
幂等性大部分都是没有问题的。比如说,你要写数据库。你insert一个记录。如果再次刷新。是不是多了一个重复的记录。网络设备大部分都不是问题。但是,如果自己做设备的agent。要测试这个特性。

Q8:下的命令和show run显示不一样 你们怎么处理的?
审计模板,下的配置可以写另外一个模板,不一样的比较少。

--------------------------------------------------------------------------
SDN实战团微信群由Brocade中国区CTO张宇峰领衔组织创立,携手SDN Lab以及海内外SDN/NFV/云计算产学研生态系统相关领域实战技术牛,每周都会组织定向的技术及业界动态分享,欢迎感兴趣的同学加微信:eigenswing,进群参与,您有想听的话题可以给我们留言。


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

登录后才可以评论

SDNLAB君 发表于16-01-22
2