SDN网络与传统网络对比分析（下）

    思科服务部门对网络生命周期有个定义，首字母连起来是PPDIOO 分别代表P(Prepare)，P(Plan)，D(Design)，I(Implement)，O(Operate)，O(Optimize)。其中的前2个步骤Prepare和Plan主要从需求入手，依次明确战略，资源，关键任务，概念设计及里程碑等内容。从技术角度看可以归并到设计里。

 

    ITIL 服务周期定义分为5个阶段，分别是

 

 

    同样从具体技术层面，可以把战略和设计合并为设计。

 

    通常的网络实践经验来看，也可以总结为设计（含测试） - 部署 - 运维（含排障） - 优化四个阶段。

 

 

    MPLS网络的设计阶段最终的产出物是做好测试验证的LLD（Low Level Design）。

 

    通常在HLD（High Level Design）中明确基本布点，流量，互通，QoS等需求后要在LLD中进行量化和给出落地方案。

 

    MPLS 网络的设计，简单来说重点就是路由协议+ 设备 = 配置。 因为需要支持多种协议，要做较多考虑。

 

    设备层面：

 

 

    协议实现层面

 

 

    SDN网络只需要考虑控制器的部署位置，网元设备的端口数量，一些必要的配套服务存在等几个基本条件即可。简化了网络设计。

 

 

    部署通常包括：

 

    分配和管理各种虚拟资源：

 

    IP地址段，VLAN，AS No. 等

 

    配置模板：

 

    基于配置文件分块后大致相同的配置内容通常集中配置好，或者做初始配置后，逐个设备单独登录配置。

 

    MPLS-base网络即使有配置脚本，也需要有基于协议状态的复杂检查过程，才能确定网络部署正确。

 

    相比而言，SDN的网络设备配置简单，通常可轻松的实现自动化，部分设备还可实现启动后自动部署，其本质也是因为网元设备和控制器之间的多对一关系实现的。

 

    很难的一个事情是MPLS网络的设计加部署时间周期，把事情考虑周全了，测试验证做做，写写文档，1-2个月真不算慢的。加上设备到货，安装，没3个月以上是建不起来的。网络的搭建时间过长，这是大家都有体会也很无奈的一件事。从根上说，我理解问题还是协议/配置/设备三者之间的耦合关系过深。

 

 

    监控，变更和排障是运维阶段的三大任务。

 

    监控

 

    从共性看，拓扑发现及变化，链路延迟，丢包，流量的监控，分析，告警。是两类网络都不可或缺的功能。

 

    从区别看，MPLS网络运维需要监控多种路由协议的状态，因为是全分布式，每个协议在每个接口都可能有Peer，需要对多种状态进行监控或者事后的排障。底层故障对上层协议会造成相关影响，如何管理和屏蔽大量告警事件是挑战。

 

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

 

    监控的高级阶段一是关联和联动底层数据，二是对用户数据进行挖掘。从这个层面看，两种网络都还有很长的路要走。

 

 

    如果说大量的长途故障来自于底层链路，属于推土机挖断光纤惹的祸，那变更产生的人为配置错误是则是故障的另一主要来源。变更的原因很多（软件升级，硬件更换升级，业务部署，结构优化等等），最终都会落实到调流量，改配置上。

 

    网络部署后随着运维时间推移，各种不同业务需求对网络进行不同的要求后，很难再维护统一的配置模板了。各种临时的，非标的配置需求逐渐在不同设备上 生根发芽，枝繁叶茂。到最后，没有人去敢删除那些可能已经不用的临时配置。那些配置也就半永久的存在不同设备上。传统网络配置长在设备上，各种配置的来龙去脉又只有当事人清楚。时间一长，人，设备，需求的变化会导致配置和实际情况脱节，和现网运维人员脱节。随便说说，哪张网络没有一堆无法说清的Policy，一堆无法删除的ACL。

 

    有一种说法是：当有了netconf+Yang后, 传统CLI被替代，也可以自动化。但实际情况是，不论Yang的推广和落地时间，就算所有厂商设备都通过Netconf接口可下发，但复杂配置的一致性，配置检查及检查后的配置删除回滚以及配置管理仍然是有挑战的任务。 所以配置下发的自动化 不= SDN，归根结底的问题是分布式复杂性过多和物理设备紧耦合造成。

 

    SDN则基本摆脱了设备配置的问题。基础架构数据通过自发现和初始定义可以全部在GUI实现。业务数据通过GUI和API实现，软件升级时，控制平面的前端，后端，业务编排，底层控制器各组件既可以分别升级也可以统一升级。对转发没有明显影响。