这些自动化运维技巧让网络运维不再背锅( 二 )


当然 , 可以通过snmp采集的信息还有很多 , 例如:设备的CPU/内存/温度/防火墙的Session等 , 掌握这些信息对了解设备的工作环境也颇有益处 , 如果你要做一个自动化巡检工具 , 那么这些指标必不可少 。市面上提供网络监控的软件有很多 , 例如:Falcon / Zabbix / Solarwinds / Cacti / Nigos等 , 有开源的也有收费的 , 功能类似 , 此处不加赘述 。
制造自动化运维工具
第一章中的组合拳打完之后 , 基本上不会出现“意料之外的故障” , 所有的异常都应该有据可查 , 当SRE莫名其妙提出对网络环境的质疑时 , 你应该早已心中有谱 。
但是网络工程师的工作并非只有救火 , 日常运维工作中 , 经常需要配合业务发展做一些线上变更/ 机房扩建/业务类故障排查等 。作为一名“懒惰”的网络工程师 , 程序可以帮忙点什么忙呢?
UserDevice Tracker
这个名词借用于Solarwinds套装中的一个组件 , 直译为“用户设备追踪器”  ,  在中小型企业网运维中 , 经常会有这样的需求:

  • 知道服务器的IP , 请问连接在交换机的哪个口?
  • 知道交换机的某个端口 , 请问连接的服务器的IP是多少?
  • 给你一台服务器的mac地址 , 怎么知道在哪个交换机的哪个口?
大型互联网公司一般会有CMDB或者网络管理平台来记录这些信息 ,  但是如果你是一家中小型企业的网管 , 没有运维研发团队做支持 , 并且还在沿用二层的环境(服务器网关在核心设备) , 那就比较费劲了 。以上几个问题其实归根到底是要捋清楚三个要素的对应关系:PORT<>MAC<>IP。
举个例子:
这些自动化运维技巧让网络运维不再背锅

文章插图
一台交换机有多个物理接口 , 一个物理接口下可以有多个MAC , 一个MAC可以对应多个IP , 或者不对应任何IP 。有了这个基本的模型 , 只需要做两件事情即可找到全网设备这三元素的对应关系 。
首先去服务器直连的交换机获取MAC表(即MAC<->PORT) , 然后再去服务器的网关设备获取ARP表(即IP<->MAC) , 这两张表根据MAC地址作为唯一主键即可得到PORT <->MAC<->IP的对应关系 。
信息的获取可以通过模拟登陆或者OID采集均可 , Github中也有很多类似的代码可供参考 , 有了这个对应关系 , 即便没有CMDB , 你依然可以快速定位想要的信息 ,  普通网工查找这个信息需要5分钟 ,  而你只需要5秒钟 。
网络设备北向接口的二次封装
日常网络运维工作中 , 经常会有一些 “简单重复劳动” , 例如:为某个接口划分Vlan/给某台设备添加一条指向主机的路由等 ,  这些操作既没有科技含量 , 还占用了工程师宝贵的时间 , 更要命的是再简单的人肉操作 , 重复的次数只要足够多 , 总有失误的时候 , 正所谓“常在河边走 , 哪有不湿鞋” , 但是在这种问题上犯错误简直是对职业生涯的抹黑 , 如此“鸡肋”的工作怎么才能干得漂亮?
以《自动划分交换机接口Vlan》的功能为例 ,  如果有一个工具只需要你提供三个参数:设备IP/端口/vlan编号 ,  就能自动登陆设备把特定接口划分到指定Vlan , 那岂不是美哉 。
没错!你需要的是一个对设备封装后的接口 ,  现在多数网络设备厂商都会提供自己的API , 无论是NETCONF还是RESTful , 只要读懂了使用手册 , 即可通过程序轻松变更设备的配置 , 甚至你可以用更加”接地气”的方法 , 用程序“模拟登陆”设备  , 虽然这个方法在效率上比不过NETCONF和RESTful API , 但是在通用性上那简直无敌 , 因为没有哪个厂商的设备不支持SSH或者TELNET的 。
有了这个理论基础 , 一些简单的网络上的操作就可以通过自己封装的接口来实现变更 , 甚至可以把变更的权限交给业务 , 只要业务提交的请求是合法的 , 变更可立即上线生效 。


推荐阅读