SD-WAN和云专线浅见

2021-04-16 09:25:55 云杰 101

  12SD-WAN668.jpg

         随着相关技术的发展,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的本质:按照人为管理需求设计,实现统一策略制定、修改、执行的软件平台。