浅谈SDN架构下的运维

目前国内的网络运维还处于初级阶段，工作人员每天就像救火一样，天天疲于奔命。“什么破网络怎么又断了”，“我去，服务器宕机啊”，“这个网速慢的跟乌龟爬的一样”，这些埋怨声每天都在运维人员耳边回荡。运维人员只能埋头查找系统运行的日志，耗时耗力，老眼昏花不说，有时候忙了半天还一无所获，作为运维工程师的你，有木有遇到过类似苦逼的经历?

传统网络的运维痛点：

传统的网络运维每天都是针对不同的厂商设备敲不同的命令行，从 Cisco、Juniper、到华为、华三，变化的只是换一种命令show / display 、no/undo。网络管理分散，网络和云管平台、安全、IT/业务系统互相独立，需要分别维护，效率低；网络结构，配置、拓扑、链路状态的不可视化，运维人员只能依赖经验和记忆，变更调整网络，这为网络留下了大量隐患；管理模式单一，基于单设备或单机架构管理，错漏多、排障难等等。当网络出现问题时，公司的各个大小部门都在埋怨运维部门，可是运维人员也很无辜，每天面对繁杂的工作不说，最后出了问题也只能“打碎牙齿和着血往肚子里面咽”，成了名符其实的“背锅侠”。

运维部门每天都要制定不同的规章制度，较大规模的公司会有自己的开发人员对开源软件和开源产品做二次开发。在传统的网络中，随着企业业务上涨，该公司的网络运维部门规模也会跟着扩大。一个典型的网络运维部门，开始团队只有十几人，当四五年后，业务系统变得复杂，网络设备涉及的种类越来越多，运维人员也越来越多，基本翻了两倍。他们每天都需要7*24小时值班，哪怕是已经下班回家的工作人员也是手机不离身。处理旧的故障时会有故障模板。当遇到新的故障时，除了要辛辛苦苦找方法解决，最后还要再写新的故障模板。于是，运维人员的故障模板库越来越来越长，越来越复杂。然只能叹息“吾心甚累！”

网络的发展

网络在发生什么样的变化？我们只能看到网络的变化，才能看到网络运维需要对应做什么变化。

从1974年TCP/IP协议的发布，到今天的SDN,网络技术一直在发展。在这期间产生了快速以太网、MPLS、SDN技术、Openflow 1.0以及后续的版本、Open Daylight的发布等，促进了网络的发展。

20世纪60年代，很多大学和研究机构都在致力于新的通信技术，其中有一家美国国防部最为突出，当时为实现迂回的通信传输方式，分组交换方式便应运而生了。到20世纪60年代下半叶，已有大量的人员投入分组交换和分组通信的研究中。后来为给互联计算机中提供可靠的通信，到1982年全球性的组织提出了TCP/IP协规范，1990年左右不论是局域网还是广域网，都开始倾向TCP/IP协议。

互联网投入商用是从1995年开始，当时互联网服务供应商数目剧增，1996年IPv6规范出炉，载入RFC。
1995年开始做快速以太网标准，1997年IETF成立MPLS工作组。2005年中国出现了电信级以太网概念，同年，全球骨干网络基础建设大规模兴起。

2006年了SDN 诞生，从诞生至今，在中国商用落地的项目并不多。2009年的时候，Openflow1.0 正式发布，在全球掀起了一阵风潮，大家开始意识到网络要改变了。2011年开始 ONF 的成立又掀起另一股浪潮。2012年谷歌B4全面运行，2013年 OpenDaylight 发布，2014年 ONOS 发布。各行各业的玩家开始进入SDN领域。

那SDN是什么

SDN是Software Defined Network的缩写，也就是软件定义网络。SDN是一种网络架构，将网络的控制平面与转发平面分离，并通过开放和可编程接口直接对控制平面进行编程。SDN的核心理念就是希望通过应用程序来控制转发行为，完全通过软件来定义整个网络。

SDN架构分为应用层，控制层和基础设施层：（1）应用层包括各种不同的业务和应用，负责各种网络资源的编排；（2）控制层也就是SDN的控制软件，负责处理各种数据转发资源，维护网络拓扑、状态信息，进行网络全局管理；（3）基础设施层包含了各种网络设备，负责数据的处理、转发和状态收集。

SDN是对现有网络架构重新构建的技术。传统网络架构是由交换器、路由器等网络基础设施定义的网络流量的传输，就像城市道路上的车流一样，在没有GPS导航前，每个十字路口如何转向，基本是司机根据当前看到的情况走自认为最短最好的路径，但高峰时段往往塞成一锅粥。而SDN是从全城动态交通状况，根据每辆车的需求（如时间最短、费用最省、不走高速等）来安排调度每辆车如何到达目的地，从全局视角调度，也保证了每辆车的最优线路。

SDN技术因其架构的开放性和灵活部署及编程能力，成为下一代网络核心技术的首选。无论是Google对于其DC（数据中心）系统完成的SDN改造，还是IT巨头微软和阿里巴巴分享的SDN云服务经验，无一例外都为此技术的应用描绘了美好的前景。基于SDN的网络虚拟化，能够将业务的逻辑网络拓扑与物理网络拓扑解耦，极大提升业务交付速度，简化网络运维，同时能够满足运营商、政企对于降低网络成本、提升业务创新速度的诉求。

SDN给运维带来的优势

传统网络由具有集成控制和数据转发平面的设备组成，因此每个盒子都需要独立配置和管理。即使对网络进行简单更改也可能需要数周甚至数月才能完成，因为必须对每台设备进行更改。但随着物联网（IoT），云计算和移动性的兴起，SDN架构中控制和数据平面的分离使控制能够从设备中抽象出来并集中化，以便网络管理员可以集中控制管理底层复杂基础设施。从理论上讲，所有网络节点只需要转发或数据平面来推送数据包。SDN给运维带来的优势具体如下：

• 减少开销
  由于网络管理员不再需要从一个设备到另一个设备来更改网络配置，因此他们可以更有效地进行必要的更改。不仅可以通过集中控制有效地控制网络配置，还可以自动化许多配置。
• 整体的集中式网络管理
  SDN方法的最大好处之一是可以通过单个设备控制所有网络组件。物理和虚拟设备都可以通过单个API进行控制，使得网络管理员的生活更加轻松。
• 启用“无网络影响的网络实验“
  SDN为网络带来的灵活性允许管理员“跳过”SNMP所施加的限制并尝试网络配置，而网络也不会受到影响。
• 更详细，粒度安全
  虚拟化，云计算和移动设备为信息安全带来了重大挑战。SDN控制器提供单点控制，其中信息安全策略和规则可以在整个组织中分发。此外，SDN控制器还提供了一个附加点，可以放置安全策略来解决特定的软件和应用程序漏洞。
• 提高应对网络威胁的能力
  SDN通过为IT人员提供网络活动的实时可见性，帮助他们应对安全事件。您还可以对网络进行编程，以自动响应某些类型的事件，从而减轻人为依赖。例如，假设有一台笔记本电脑检测到有人正在发送恶意软件或攻击另一个系统。SDN允许您对网络进行编程，以根据设备地址或应用程序等属性有选择地阻止特定流量。
• 提高对网络的可见度
  整体提高组织网络的可见性是软件定义网络的最大好处之一。首先，集中控制可以识别网络安全性，性能和挑战。所有这些都可以在不干扰网络活动的情况下进行分析。通过找出带宽或安全挑战的源头，可以在网络中断之前防止中断和停机。
• 可扩展性
  此外，这种集中化的灵活性允许包含更多选项，因为SDN允许程序员编写公共接口并管理多个设备，而无需了解网络上每个设备的复杂功能。
• 更有效地使用网络资源
  在传统网络中，确定数据如何传播的网络控制平面位于硬件中。在SDN基础设施中，控制平面是独立于网络硬件操作的软件功能。这种网络和数据控制平面的逻辑分离使SDN能够支持高级应用和服务，包括大数据分析，同时跟上不断增长的网络服务需求。
• 提高正常运行时间和可靠性
  SDN程序内置的灵活性和冗余可以消除在部署网络期间可能发生的人为错误。此外，SDN支持大多数物理和虚拟网络设备的虚拟化，允许您在网络的一个组件上执行升级或替换，而无需使整个系统脱机。在发生停机时，SDN支持对配置进行快照，从而可以快速地从升级导致的中断中恢复。

网络的未来将越来越依赖于软件，SDN在应对传统网络方法所面临的许多挑战方面迈出了一大步。IT通过提高可见性和安全性，同时简化和自动化操作，将网络运营带到现代领域。

SDN运维工具的改变

在传统网络运维中，运维规章制度定了那么多，运维人员能做到的其实也就那么多，针对不同厂商的硬件设备敲不同的命令行，出现问题查查日志，写写故障报告。SDN网络的主要特点是集群化、采虚拟的软件网络数据流，通过图形化的方式简易呈现，方便业务上线，以及后期内容的维护。那么SDN这么牛，难道就不需要运维工具了吗，答案当然是否定的！

在 SDN 系统里，有独立的中央控制器和上层应用层，转发层只是作为最底层的数据转发，业务编排在控制器做，控制器是纯软件系统，这套系统可以实现对外API对接，这时候 DevOps 就派上用场了。

DevOps促进开发人员，运营团队和基础架构专业人员之间的沟通和协作，以实现统一和自动化的IT开发，实施和管理。同时，SDN允许工程师将软件控制应用于网络元素，集中管理和配置大量虚拟和物理基础架构。

SDN与NetDevops相遇

DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。它是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。它的出现使软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运营工作必须紧密合作。

DevOps和自动化网络需求
DevOps利用小型applet（或微服务）中应用程序的组件化，这些applet 可以分布在一系列数据中心资源（即公共云或私有云）中。容器（例如，Docker）正在成为快速引入新微服务流行方式。

微服务和DevOps应用程序需要快速配置计算和存储网络资源，使其能够快速运行，根据需要进行扩展，以高可靠性执行并保证服务的安全性。网络需要管理工具来满足开发和自动化的需求——减少停机时间和处理时的复杂性，同时又不需要发送Opex的数据。。

网络负责为DevOps应用程序快速配置适当的资源，并在保护和管理这些快速迁移的应用程序方面发挥关键作用。然而，微服务的敏捷性和快速变化的要求挑战了传统网络的能力。应用程序的分解意味着手动网络的移动部件太多 - 因此网络自动化至关重要。使用DevOps预先测试网络资源的能力对于减少应用程序部署时间非常重要（例如，返回修复网络问题）。基本理想：开发人员不必担心网络资源，包括IP地址或防火墙规则。

SDN，DevOps和自动化相遇的地方
软件定义的网络优化了开发和自动化的网络，使部署复杂应用程序的IT组织能够快速提供网络资源和服务（包括安全策略）。SDN支持对网络进行集中管理，并将（手动）配置的挑战从人员转移到技术上，降低运营成本。

基于SDN的网络可以自动检测流量变化，并根据应用类型，服务质量和安全规则等参数选择通过网络获取的路径数据。软件控制平面管理和隐藏网络复杂性，能够使10,000个交换机看起来像一个。SDN可以指示网络提供与其相关应用程序一致的服务，并支持快速部署大量新应用程序和微服务（例如，容器）。

SDN提供自动化网络流程的能力，以快速为DevOps应用程序提供网络/安全资源。它可以通过将（手动）配置的挑战从人员转移到技术来降低运营成本。许多超大规模的云提供商 - 包括谷歌，苹果，Facebook和微软 - 已经部署了SDN技术，以帮助自动化其网络的配置和管理。IT领导者应考虑部署SDN以满足其DevOps团队和相关应用程序不断变化的需求。

再谈SDN 运维工作，SDN有那么多优点，那么运维工作会不会很轻松呢？SDN运维工作主要包含两个方面，一个是日常运维、二是工程项目。日常运维工作和传统的网络运维类似，值班监控，一二线故障解决，以及和各部门沟通。

重点是跨部门沟通，传统的网络运维因为很多设备和功能都是相互捆绑的，相关的功能函数并不对外开放，只有设备供应商自己清楚，所以运维常常是一个封闭的部门，和开发并不会有太多的交集。但是进入SDN的时代以后，运维会涉及到很多部门，例如测试、研发等。这时运维已不再是封闭的，需要从一个新的角度去看待这个岗位，需要提前与开发部门、测试部门的网络工程师做互动，这一点和DevOps的要求也是很符合的，即为了按时交付软件产品和服务，开发和运营工作必须紧密合作。

SDN运维用到的工具和传统网络运维类似，主要有 Cacti、Smokeping、Nagios、Zabbix。但是现在更加讲究开源，开源更能促进SDN和网络技术的发展，运维工程师可以从中学到更多关于网络的知识，对于网络会拥有更多的自主管理权，工程师还可以在开源的软件上根据自己需求做二次开发，较传统的封闭式运维大大减少网络运维成本和提高运维效率。

SDN自动化运维

运维包括告警监控、变更、排障三个阶段。在介绍告警之前谈一下运维人员需要关心的SLO和SLI,其次会简要分析监控，分析，变更和排障。

运维服务质量设计
在传统的网络运维中，网络工程师们都关注SLA,但作为运维的人都会关注SLO和SLI。我们需要找到服务质量的指标是什么，根据指标制定目标。SLI是经过仔细定义的测量指标，它根据不同系统特点确定要测量什么，SLI的确定是一个非常复杂的过程。SLI要回答要测量的指标是什么，测量时系统状态怎么样，如何汇总处理测量的指标，测量指标能否描述服务质量，测量指标的可信度。主要关注性能、可用性、质量、内部指标和因素人这几个方面。SLO(服务等级目标)指定了服务所提供功能的一种期望状态。SLO里面应该包含所有能够描述服务应该提供什么样功能的信息。服务提供者用它来指定系统的预期状态；开发人员编写代码来实现；客户依赖于SLO进行商业判断。SLO里没有提到，如果目标达不到会怎么样。网络时延、丢包率以及端到端都可以作为衡量的指标，我们根据这个指标制定SLO。

SLA是一个涉及双方的合约，双方必须都要同意并遵守这个合约。当需要对外提供服务时，SLA是非常重要的一个服务质量信号，需要产品和法务部门的同时介入。
本段参考深度剖析什么是 SLI、SLO和SLA？一文

监控告警
SDN能更多的进行白盒监控，即通过对系统内部的性能指标进行监控了解系统的运行状态。从南向接口看，SDN只需要监控少数几种协议，监控相对简单，而面对业务变更时更是可以随着API变更而变更。主要复杂度集中在控制平面和业务编排，监控业主要集中在控制平面健壮性，用户业务状况以及控制转发的一致性等方面。在大型网络里因底层链路故障导致的大量路径计算和重新优化需要控制及时，反应要快。面向最终用户的web接口又会需要对各种请求和配置变更做出实时响应和分析。
本段参考SDN网络和传统网络方案对比一文

运维系统中监控告警设计，通常从最底层的采集开始，自上而下设计，其次是存储、功能模块开发、上层告警通道、用户侧。从采集的方式上来说要根据网络架构来选择是采用集中式的，还是分散式的。如果网络中的转发节点较多，那么在这种情况下就无法采用集中式。需要根据自己的业务分布点，制定不同区域性的分布采集，包括存储。部署中央存储和分布式存储，分布采集后实时同步到中央存储，同时需要在本地存储后做备份。

功能模块方面通过在底层采集原始数据，根据原有系统的规则，从监控告警到告警通道，做一个中间层，这网络管理人员可以根据自己网络情况做的自定义的规则。

拿到原始数据后，如何将数据更好的展现出来，将有用的信息实时同步。SDN中实时告警不像传统网络只在底层转发，现在它可以对业务系统和网元进行实时监控（操作系统的稳定性）。有了告警信息以后，对它进行分类，然后才能做接下来的告警分析。

日志统计分析
日志统计分析，现在大多是公司都使用ELK来分析。该软件可以根据自己的业务做不同的开发。
日志包括整个SDN系统。从上层的控制系统，中层操作系统、存储、业务编排，底层转发网元，最后底层传输。这些在传统的网络中，运维人员是不会关心的，只会关心网络设备。

流量统计分析
流量统计分析，现在网管系统和运维人员关注设备流量、端口流量，SDN 需要关注整条链路端口，更重要的是业务流量，SDN 最大的特点是能够跟业务系统做到关联，能够通过运维系统查看所有业务相关的流量信息。

变更
在传统的网络中，由于时间还有业务对网络不同的需求后，很难有统一的配置模板。各种临时的配置在不同的设备上安家。现在的网络维护人员不敢删除上一个运维人员的设定。天长日久，人，设备、需求的变换会导致配置和实际状况脱节。SDN则基本摆脱了设备配置问题。基础架构数据通过自发现和初始定义可以在GUI上实现。业务数据通过GUI和API实现，软件升级时，控制平面的前端、后端、业务编排、底层控制器各组件既可以分开升级也可以统一升级，对转发也没有明显的影响。

自动化排障
SDN排障更多的是与Devops结合，通过软件化手段解决。一个好的故障处理系统能够自愈和关联分析。当出现多个警告时，如何让这些警告自动关联，然后生成一个真正一个有用的。故障自愈就是在关联以后，故障不需要人为的干预就可以自愈。

未来传统的运维人员将何去何从

基于SDN技术的未来电信网络架构的演进对运维流程产生了深刻的影响，电信技术与IT技术的融合对参与系统的运维团队也提出了技能方面的新要求。

对于SDN的运维人员除了要知道传统的运维技能和运维工具以外，还要了解SDN运维体系目前从SDN系统来讲从最底层的资源，网络设备、转发网元、设备、服务器。采集部分主要涵盖 SNMP 的采集，对传统设备Netconf命令下发，对新设备 Openflow 的协议，对CLI的管理。

中间的存储是独立分开的，中间有日志、配置库、知识库，在存储部分独立分开。功能方面包括监控告警和数据采集，数据分析和统计，流程管理和项目管理，有很大一部分是资源管理，资源管理包括文档配置，这部分主要基于CMDB，功能非常强大，如何结合SDN系统用起来，要根据自己网络底层和控制器开发做制定。

SDN现在越被大多数公司采用，那对于企业来说如何培养出一个合适的SDN运维小能手呢？一般公司会选择培训现有的员工，因为他们觉得培训现有员工比寻找和招聘新员工更具经济效益。投资现有员工需要积极主动的自上而下战略，提供大量培训机会。其次从个人的角度来说网络专业人士应该把握好自己的未来和职业生涯。并不是每个网工都需要成为程序员。相反，SDN需要更广泛的网络概念和基础知识。要理解软件系统是如何工作的，但并不意味着你必须编写代码，可需要了解整个生态系统是如何运作的，以及事情是在哪里完成的。除了这些基础知识，网络专业人员还应利用任何学习的机会，建议网络专业人士在制定计划后需要坚持下去。仔细规划并专注于自己的轨迹，不要被外界情况所影响。

点击如何构建基于SDN网络的自动化运维系统可观看大河云联的工程师张永福谈如何构建SDN网络的运维。

注：本文部分内容参考老司机带你飞|怎样构建基于SDN网络的自动化运维系统？