SD-WAN和云专线浅见

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

SD-WAN和云专线浅见

一、维基定义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的本质:按照人为管理需求设计,实现统一策略制定、修改、执行的软件平台


2.2 SDN的部分观点讨论

观点1:SDN不就是一个网管吗?

个人认为这个观点并不完全算错(在于怎么用!),网管在整个网络的架构也是集中部署与呈现,部分网管还开发了配置快速下发等功能。其实,做好SDN的前提必需要有个好网管,比如我们网络架构师/工程师做业务调整前也需要一套好网管,这样更佳利于判断、调整。将SDN通常的工作逻辑分割如下图,第1步的“查看”功能往往感觉和网管类似,有时客户只用SDN的“查看”功能模块,那么的确就类似一套网管啦。当然,为了实现SDN后面的工作,是要比以前网管做更多精细化的功能。

现阶段从网管到集成SDN功能主要难度:正如上诉2.1所说,如果存在多厂商设备差异,网管对接开发工作量将极度海量,不具备实操性。当然未来采用白盒设备倒是可以采用网管演进模式,现阶段还受限于白盒设备的商用高可靠性。


观点2:SDN就是自动化流量调度、流量优化?

在2.1以及观点1的逻辑图都有表示,自动化流量调度是一个非常典型的需求,也是曾经技术无法解决的场景。通过流量调度技术,在商业价值方面可以提高负载率从而节约成本,尤其还使用了Internet+IPsec链路可以更大的降低成本。这点技术的广泛使用,还是要感谢运营商的高速光网络建设。


观点3:SDN就是实现白盒化,降低成本、屏蔽差异?

白盒化的确可以降低成本,但是现阶段相比白盒带来的成本降低,仍需要考虑产品的可靠性、稳定性、延续性以及回退能力(如果控制器失效了?)。另外一个问题,白盒设备毕竟也不是由X86组成,也需要考虑芯片能力,往往新增功能特性还是需要进行设备替换,不过P4是个蛮不错的解决方式。


2.3 WAN的说明

对于WAN就简单罗列说明下:一般企业广域网讲的多一些,比如企业的分支到总部/分支(Site2Site)、分支到DC(Site2DC)的网络;而Site2Internet一般当作互联网。其他大型行业、运营商一般会将其广域网进行明确术语划分,如运营商的骨干网、城域网、接入网。SD-WAN就是为这些广域网场景下提供的SDN解决方案。



三、业界用SD-WAN在做什么事情?

在SD-WAN如火如荼的大环境下,SD-WAN Startup企业、传统运营商以及传统设备厂商纷纷提出不同的解决方案,下面会从这几类公司分析下其SD-WAN方案思路、目标定位。


3.1 Startup企业

从上半年的业绩以及知名度,以Viptela和Velocloud作为Startup企业代表分析下其SD-WAN解决方案。


(1)、总体情况说明

SD-WAN和云专线浅见

(2)、场景化方案

场景一:企业总部(数据中心)+企业分支场景,面向客户提供“Dual Internet(多条Internet,比如不同ISP互联网接入、4G接入等)、Hybrid(一条Internet、一条专线)”链路连接分支到总部;架构模式:设备层为定制化设备或白盒+软件,控制层为SD-WAN控制器;服务模式:单纯为企业类客户提*品及服务。

SD-WAN和云专线浅见

场景二:云中心(公有云/混合云/私有云)+企业分支场景,面向客户提供“Dual Internet、Hybrid”链路连接分支到云中心;架构模式:云中心路由器(支持VNF),控制层包括SDN控制器及VNF编排器;服务模式:SD-WAN公司与云服务供应商共同为企业用户提*品与服务。云服务供应商趋于集成SD-WAN方案,优化其企业市场需求。

SD-WAN和云专线浅见


(3)、方案关键价值

Startup企业基于SD-WAN平台,实现企业用户设备的“零接触部署”,实现自动化快速部署,从而降低人力成本;


企业用户可以采用互联网接入、4G无线、MPLS专线等中继方式,基于业务进行路径优选,降低专线链路需求并提高链路使用高负载均衡,从而降低运营成本。


3.2 传统运营商

运营商在骨干网、城域网都有SD-WAN方案的实践,今天主要和大家分享下云专线方案,可能有小伙伴疑惑为何不写成Cloud***,多少洋气些。主要考虑到Cloud***同样是华为解决方案的名称,所以这样选择了运营商业界通用的叫法(政企)云专线。


云专线前期主要来源业界云运营商,比如天翼云、腾讯云、华为云等,云专线是为企业内部上云资源池提供安全、保障的专线接入通道,比如采用MSTP、MPLS ***、Vxlan等方式;不过构建这个真正的专线并不容易,涉及到传统运营商多方面配合,所以在资源协同、带宽调整等方面无法实现灵活性。


类似AWS、BAT这类云运营商,通过提高灵活性及SaaS应用层面创新,吸引了大批量的企业客户。而传统运营商为防止政企客户流失,除了要提升灵活性,还可以从管道方面拉高竞争力,从而弥补SAAS层面开发能力的不足。


(1)、总体情况说明

运营商在设计云专线方案时,主要面向:Site2Site、Site2DC、Site2Internet三种客户组网模式。针对各类运营商应用时初步梳理如下:

SD-WAN和云专线浅见

传统运营商的优势在于掌握管道入口及管道质量,进而能够提供端到端带宽的灵活调整,而云运营商一般只能控制云端互联网方向带宽调整。从上面对比表格,按传统运营商的标准,云专线方案通常指基于MSTP、MPLS ***等有保障的链路,实现业务敏捷开通、专线安全保障、带宽灵活调整。所以,建议将运营商云专线认为是SD-WAN的特定场景化方案。


运营商云专线方案中,在云端通常会提供NFV增值服务,比如vFW、vLB等。在Site2Site、Site2DC、Site2Internet三种组网模式均可基于云专线业务链技术享受云端增值服务。


(2)、场景化方案

就传统运营商的云专线方案,目前国内方案提供商主要有:华为Cloud***方案、新华三E-CORD方案、中兴Elastic***方案。给大家罗列下运营商云专线方案的简化版逻辑:

SD-WAN和云专线浅见

基于这套复杂的方案架构,现阶段确实存在模型复杂、技术门槛高的特点;毕竟在方案初期提供从下到上全产品线的厂商不多,所以基本上也只能是少数厂家和运营商的合作探索。通过该架构服务,采用SD-WAN管理设备实现企业专线快速开通;融合NFVO+VNFM产品,基于SD-WAN业务链功能使得增值网元服务的提供更加便捷;融合云管理平台,实现从网到云敏捷构建。


趋势:伴随着标准化、解耦的趋势,运营商在建模编排层面逐步会根据考虑采用合作或自研的方式,既满足业务个性化需求,又避免厂商的捆绑。另一方面,伴随网络服务逐步云化,企业终端设备将趋于白盒,少数云端NFV软件同样会向自研演进。所以,在云专线场景模式下,未来供应商很可能就是提供通用的硬件产品以及软件应用产品(主要包含厂商级控制器、NFV软件)。

(3)、方案关键价值

传统运营商基于云专线方案,真正实现云、管、端资源整合,通过电商化+自研运营模式转型,降低整体运营成本;企业用户实现期盼已久的专线带宽、互联网出口带宽、云计算资源按需使用、按需调整,而且可以享受端到端的高质量服务,实现成本与质量的双保障。


3.3 传统设备厂商

在SDN浪潮下,传统设备厂商确实会受到冲击,也在不停探索转型,拥抱SDN、NFV、软件化。当然高可靠的硬件设备仍然是设备厂商的优势,厂商依此提供的SD-WAN解决方案相比Starup企业具备可靠性与安全性的优势,毕竟广域网的故障影响范围是极其广泛的。


设备厂商除了在管道使用方面实现SD-WAN进行流量调度优化,还可以从传输层优化、应用层优化方面进一步优化广域网链路质量,这也是为什么WAN优化设备厂商同样需求支持SD-WAN流量调度优化的缘故。



四、SD-WAN有几件比较重要的小事

1、控制器高安全、高可靠设计。SD-WAN控制器通常会部署在服务器上面,除了在物理服务器实现高可靠,更关键的SD-WAN控制器本身的高安全设计,未来整个网络的决策关键都在控制器上,所以SDN的网络级和应用级高安全性均需尽早规范。


2、调度参数高精化、规范化。基于带宽的流量调度已经相对成熟,但是未来将会根据实时监控的质量,比如时延、抖动、丢包进行多路径的调度,那么此刻这些参数值再精确都不为过,因为这就是未来的选路协议。但是目前业界都只是各厂商进行优化,并没有标准统一明确精确度,所以造成客户往往缺乏使用的信心。


上一篇:Prometheus基于consul的服务发现


下一篇:混合WAN和SD-WAN的差别