SD-WAN和云专线浅见

 随着相关技术的发展，SDN快速应用于各行各业的不同场景。2017年，在广域网领域SD-WAN和云专线词汇热度特别突出，应该SDNLAB小伙伴邀请，做一期SD-WAN分享云专线的观点。本人结合SDN/NFV从有限的角度与大家讨论，欢迎大家指正。

一、维基定义SD-WAN

SD-WAN是广域网软件定义的缩写(Software Defined-WAN)。SD-WAN简化了网络硬件与其控制机制的分离WAN管理与操作。

SD-WAN关键应用程序允许公司使用低成本的互联网接入来构建更高的性能WAN ；替换部分或全部昂贵的广域网专用链路，如MPLS。(摘自: en.wikipedia.org/wiki/SD-WAN)

二、探索SD-WAN

首先，这确实是个仁见仁、智者见智的话题。先做一个简单的SD-WAN主要由两部分组成SDN WAN。我先从这两个纬度探索。

2.1 SDN的解读

罗列下对SDN一般理解：转向控制分离和开放接口编程（许多行业专家在早期阶段进行了多纬度分析和解释，建议您可以参考更多，值得回顾）SDN一般来说，我总是认为它只是呈现了外部形象（技术形式），而不是真正的灵魂（本质需求）。我希望我能看到转移控制分离和开放接口编程思想背后的本质SDN概念更好，通俗易懂。

转向控制分离是传统思维定势的主要理念创新。虽然我们现在认为转向控制分离的想法并不奇怪，但我们曾经习惯于设计路由来实现业务选择，并将其视为不可动摇的行业真理。我对转向控制分离的理解是，它不仅分离了设备的控制水平，而且分离了架构师/工程师的思想水平SDN控制器。

假设一家企业从上海到南京有两条中继链路，链路A延迟质量为30ms，链路B延迟质量为80ms，我们的架构师根据链路质量设计主要链路IGP的Metric制定业务优先路径。但实际情况是，链路质量会发生变化，如链路老化、传输倒环等，很可能导致链路A此时，架构师只能根据业务经验被动地对端到端和段进行分析和调查。如果这类问题是间歇性的，调查的难度将增加几十倍。此时，设备的控制水平特别不周到。我们只能在设备水平上处理重大故障，不能根据实际链路质量变化优化流量转发。因此，我们已经容忍了很多年。转移控制分离计算应运而生。从架构师/工程师那里，将网络的查看、分析、判断和执行的一系列想法分离出来，制成软件产品，即SDN控制器，此时网络将有一个实时在线架构师/工程师来保证业务，这应该就像第一代人工智能。

下一步就是SDN产品设计收集了现阶段主体的需求，细化了对客户的价值，如缩短网络自动化部署时间、优化流量调度、减少企业支出等。在实际的产品化中，由于硬件能力和软件概念的差异SDN开发商提供的产品功能和主要场景或多或少会有所不同，因此在为客户选择方案时会增加很多难度。开放的接口编程能力变得非常重要：

SDN开发商只能提供通用的功能，并不能真正完成客户的全部需求。软件化意味着未来控制层面任何想到的功能都可以使用控制器去实现，所以SDN控制器二次开发是许多用户的需求。

如果不是白盒子，那么异构网络也是一个永恒的主题，毕竟，每个设备都说一种方言，因为控制器的难度可以想象，尽管有开放的接口编程能力，还有很长的路要走。因此，一些大型行业客户将要求所有设备制造商提供SDN控制器，客户使用自主研发的超级控制器，这也是屏蔽设备复杂性的好解决方案。

回归SDN本质：根据人工管理需要设计软件平台，实现制定、修改和实施统一战略。