怎样构建基于SDN网络的自动化运维系统？
|
《怎样构建基于SDN网络的自动化运维系统？》要点：
作者简介：
前言我是来自大河云联的张永福,今天的下午场是基础架构.之前五六年的时间,我一直在 Cisco 厂商做运维,去年加入大河云联做SDN网络架构设计和自动化运维系统设计.构建基于SDN网络的自动化运维系统这个话题谈得有点早,SDN 在中国刚刚起步,明年和后年,会有更多人接触到 SDN 这个新技术的运维.希望更多现有的运维人员可以参与到 SDN 网络运维,使中国的 SDN 更快的发展. 今天分享以下几部分内容：
1、网络技术演进1.1 历史回顾网络已经发展了几十年,我们进行简单梳理,可以分为如下三个阶段.
1.2 SDN的兴起
左侧 Linux 基金会、ONF、ON.LAB,是国际知名的三个 SDN 相关的组织.中间部分是开源项目,包括 ONOS、ODL、OPNFV,现在 ONAP 正在进行 OPEN-O 和 ECOMP 两个项目的代码合并. 右侧是相关厂商,包括 Barefoot、bigswitch等,这些都是做SDN芯和盒子的硬件厂商.这几年,这些国际部分SDN发展都很快,最右侧是近几年的初创公司,包括Viptela、velocloud,最后两个是做CX、IX、DX业务. 在国际上,不管是开源组织、开源项目、初创公司还是与SDN相关的项目,在国内发展确实比较缓慢,我没有列出国内SDN相关的公司,能商用落地的少之又少. 2、传统网络运维现状
SDN 运维到底涉及什么?传统网络运维,满墙的运维规章制度只是给人看的,能真正落实执行多少,大家比较清楚.贴了再多的制度,而网络运维人员在做什么呢? 针对不同厂商的硬件设备敲不同的命令行,从 Cisco、juniper、到华为、华三,变化的只是换一种命令show / display 、no/undo.网络运维在整个运维体系里背锅背得最严重,上层业务出现问题,会时不时的把这个锅扔到网络运维,网络运维没地方扔,要么自己背,要么挖掘机来背.
运维部门每天在制定不同的规章制度,有些规模的会有自己的开发人员对开源软件和开源产品做二次开发.这些年,我一直参与大型网络的运维,几年前接触过一个典型的网络运维部门,开始他们团队只有十几人,当四五年后,业务系统变得更复杂,网络设备涉及的种类越来越多,运维人员也越来越多,基本翻了两倍.他们在做的就是 7*24 小时值班监控,告警不断的响.不停的写各种故障报告,编出各种各样的故障报告模板.这是我们正常网络运维在做的事情,这也是传统运维的现状. 3、SDN网络运维3.1 DCN网络架构变迁网络在发生什么样的变化?我们只能看到网络的变化,才能看到网络运维需要对应做什么变化.
这是 DCN 网络架构变迁,也是典型传统的三层组网拓扑,相信大部分网络运维人员现在维护的网络基本上都是这种网络.
这是基于 FABIC 设计的虚拟网络架构,接触 SDN 比较多的人应该知道这张图,这是 Facebook 前几年提出的DCN架构图,现在 Facebook 已经实现了基于 FABIC 的架构设计.为什么采用这种方式,原因是现在 CLOUD、NFV 等虚拟化技术发展太快. 普通的三层组网架构无法满足现有的虚拟化业务发展.本来云就是一个很复杂的虚拟化架构,无法用传统网络架构支撑它,于是慢慢衍生出基于FABIC这样的软硬结合的虚拟网络架构. 3.2 骨干网络架构发展骨干网络技术演进,我们今天主要说的是区域骨干网络架构系统.
这是中国某张骨干网架构图,大概是二期的.本图发展将近10年,有变化吗?有,增加了点和线,看上去更像一张蜘蛛网.
这是基于?SDN?设计的网络架构图,也可以在?internet?上找到,这是?Google?前几年的设计图.底层是转发网元,分为不同的?Site,中间是控制面.在中间层的时候,controller?使用不同的功能模块实现对底层网元的控制.流量的调度和优化在最上层的?TE server?上做. 3.3 SDN NetDevOps
网络工程师对 DevOps 的理解不如做系统开发的工程师,这里就需要不同工种的协同工作.上面是 DevOps 能力环,从规划、代码到测试、发布完成一个全流程闭环,另外一个是 DevOps 关联的的研发、测试和运维三个部门工作关联图,交集的地方就是 DevOps.
重点谈谈 Network,这是针对后续几年,相信在国内是很大的空缺.DevOps 面向的人群更多的是系统开发、系统运维,原有的网络系统是属于传统网工做的. 现在国内传统网工会脚本的都不多,能否让传统网络和 DevOps 结合起来?答案是可以,现有的传统网络可以和 DevOps 结合,形成 NetDevOps.在 SDN 出现后,NetDevOps 可以发挥更大的优势. 在?SDN?系统里,有独立的中央控制器和上层应用层,转发层只是作为最底层的数据转发,业务编排在控制器做,控制器是纯软件系统,这套系统可以实现对外API对接,这时候?DevOps?可以真正体现出价值. 传统网络如何和?DevOps?结合?现有的传统网络设备是闭环系统,目前大部分的网络设备还是基于?CLI?命令行,新的硬件?OS?系统支持?PCEP、NETCONF?等协议,DevOps?和?Network?只能结合到这里,无法跟业务层做关联和适配. 3.4 SDN的运维工作
SDN 运维工作,主要包括两方面,一是日常运维工作,二是工程项目.日常运维工作和现在传统网络的运维相似,包括值班监控、一二线故障处理、各种会议、各种报告以及跨部门沟通. 重点是跨部门沟通,如果你现在从事传统网络运维,你打交道的部门是有限的,这是一个相对封闭的部门.它跟上层、应用部门的关联度很低,SDN化后会涉及很多部门,因为 SDN 的运维要参与测试、研发.这时候你的运维要提高一个层面,要更多的跟系统开发、软件开发做互动,DevOps运维恰好也涵盖了这三个方面. 运维里还有一个重要的部分,引入工程项目.这里的工程项目指的不是网络运维、网络设计的项目,指的是与软件开发、软件架构设计以及架构优化相关的,统称为工程项目. 新的功能开发包括已有功能开发优化,这部分是网络运维在做的.这个部门是由网工和软工组成的SDN运维部门,也可以是一个虚拟团队,这样的工种搭配在SDN运维里非常常见. 在去年以前,谷歌 SRE 很出名,SRE 的书翻译成中文,至今非常火.建议做网络运维的人可以看看这本书.这本书提到这两部分,里面有一段话说得特别好“任何一个运维工程师要有50%的时间用来开发、写代码”. 在SDN里,不仅仅是网络设备,不需要你直接敲命令、登陆设备,他的操作、运维、管理很多要靠系统完成,系统是需要开发的.如果你的大部分时间被日常运维占用,牺牲的是你的经验. 3.5 SDN运维工具
SDN 运维的常用工具,在传统运维和系统运维也会使用,包括 Cacti、Smokeping、Nagios、Zabbix,我们更倾向于开源,传统网络更倾向于闭源,需要网络工程师学习更多的开源软件,自己做二次开发,做出适合自己日常运维的工具. 4、SDN自动化运维运维包括告警监控、统计分析、运维自动化和运维系统的建设.SDN自动化运维系统,这个系统并不是一个平台、一个工具,而是一个体系、一个方法.平台是运维系统的一部分,运维自动化完全跟开发相关,它不在平台内,平台内更多的是监控告警、统计分析,做到运维系统的建设.运维自动化更多的与 DevOps 相关. 4.1 运维服务质量设计
运维服务质量,在传统的网络运维里,网络工程师经常提出 SLA.作为运维人员没必要关心 SLA,SLA 是服务质量协议.运维人员需要关注的是 SLI 和 SLO,我们需要找到服务质量的指标是什么,根据指标制定目标. 至于SLA,这是和用户之间承诺遵守的协议,我们在传统网络里更多的关心网络时延和网络丢包率,我们需要考量更多的服务指标,很多跟上层应用做关联. 网络时延、丢包率以及端到端都可以作为衡量的指标,我们根据这个指标制定SLO,例如,你的时延要少于50毫秒,可用性要大于99.9%,这是运维人员需要关注的部分. 4.2 监控告警设计
运维平台、运维系统里涉及的内容,一是监控告警设计,通常从最底层的采集、存储、功能模块开发、上层告警通道、用户侧.从采集来讲,如果运维只是IDC或者城域网,这时候你需要集中采集、集中存储. 如果你维护的是全国性乃至全球性的网络,你需要分布式采集.现在大河云联的SDN控制器管理着分布在全球将近100个转发节点,对于这种规模,无法采用集中式,需要根据自己的业务分布点,制定不同区域性的分布采集,包括存储.部署中央存储和分布式存储,分布采集后实时同步到中央存储,同时需要在本地存储后做备份. 功能模块方面,只提到数据分析,为什么监控告警和告警通道之间增加了一层分析,你在底层做采集的时候,采集的是原始数据,规则是通过原有系统的规则,从监控告警到告警通道,做一个中间层,这是根据自己网络情况做的自定义的规则. 4.3 监控告警分析
告警统计分析,拿到告警原始数据后,如何更好的展现出来,如何把有用的信息实时同步.实时告警不像传统网络只有底层转发,这涉及业务系统的实时监控和网元实时监控,包括操作系统稳定性的监控,都会统一的在一个监控平台做. 告警统计,需要对所有告警信息做分类管理,只有把有用的信息分类后,才能进行第二步分析.报表管理,很多 SLI 和 SLO 的来自于报表,不管是设备、链路、系统的可用性从何而来,这是通过告警统计分析报表功能输出,你可以定月、定周对设备、链路做SLA需要的统计. 4.4 日志统计分析
日志统计分析,(左图)引用了没有做二次开发的图,很多公司都在用ELK,这是ELK的分析功能,可以针对自己的业务系统做不同的定制开发,可以制定住不同的统计分析模块. 日志包括全套SDN系统,从上层控制系统,中层操作系统、存储、业务编排,底层转发网元,这里的网元包括多种类型,最后是底层传输.这是传统网络不会涉及的,传统网络的网络运维人员只会关注网络设备,在 SDN 系统里,日志采集以及运维管理包含底层传输和上层应用. 4.5 流量统计分析
流量统计分析,现在网管系统和运维人员关注设备流量、端口流量,SDN 需要关注整条链路端口,更重要的是业务流量,SDN 最大的特点是能够跟业务系统做到关联,能够通过运维系统查看所有业务相关的流量信息. 4.6 系统分析
系统分析,对于大部分运维人员来说比较容易理解,这是物理服务器资源和操作系统资源. 这几个片子重点是 DevOps,控制器的开发和上线,用了这几年比较热的精益管理、敏捷开发,相信在座了解很多.
持续交付,指的是 SDN 控制器系统的持续交付,做到版本的快速迭代和实时响应,利用流程管理来打破研发、测试、运维之间的隔离墙.与运维相关的是自动化部署、自动化测试和集成测试.
自动化部署,可以集成到自动化运维平台里,可以作为一个模块集成到运维系统里,从发布、部署到交付运行,可以采用轻量简洁的工具,例如目前比较流行的 ansible.
自动化测试,测试分为两部分,一是自动化测试,二是集成测试.自动化测试主要对控制器开发、代码的逻辑性,更多的是与研发部门的沟通.
集成测试,这比 DevOps 提到的多一个集成测试,因为 SDN 运行场景更多的转发面的设计.自动化测试是验证代码的逻辑性,对部分场景需要用集成测试完成,包括功能性测试、异常测试和场景回归. 5、SDN运维体系架构
自动化运维架构体系,前面已经提到了很多内容了在这里做以架构概览做下总结. 目前从SDN系统来讲从最底层的资源,网络设备、转发网元、设备、服务器,采集部分开始,主要涵盖 SNMP 的采集,对传统设备 Netconf 命令下发,对新设备 Openflow 的协议,对CLI的管理. 中间的存储是独立分开的,中间有日志、配置库、知识库,在存储部分独立分开.功能方面包括监控告警和数据采集,数据分析和统计,流程管理和项目管理,有很大一部分是资源管理,资源管理包括文档配置,这部分主要基于CMDB,功能非常强大,如何结合SDN系统用起来,要根据自己网络底层和控制器开发做制定. 故障自愈和关联分析,如何让告警信息形成关联,出现10个告警时,能否在你的手机或者邮件上看到10个告警,真正有用的只有1个.故障自愈系统是在关联分析后实现的,当出现10个故障,如何让故障自动消失,不需要人为干预管理,这是自愈的功能.另外需要有安全策略贯通底层和上层.告警渠道可以包括邮件、WBE、微信、Call Center等.最上层为不同的权限用户入口.
故障处理流程,在大部分的网络运维里只有第一项,运维中心在做的是受理用户故障申告以及接收监控系统告警,自动化运维平台流程里会增加故障自愈系统,根据场景开发定制,输出处理建议. 当你今天收到用户和系统的申告,如何让告警下一次不再出现,这需要我们工程师制定这样的场景,根据处理逻辑形成闭环,逐步的完善自动化运维系统. 原文来自微信公众号：高效运维 （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
