SD-WAN解决方案(1)
多年来,软件定义的广域网(SD-WAN)利基市场被认为是一群初创企业。现在不再是这样了。SD-WAN市场利用网络虚拟化来利用、管理和保护互联网宽带,为企业应用构建更强大的网络,SD-WAN企业网络服务正在蓬勃发展,预计将达到数十亿美元,包括云安全等辅助产品。
企业和服务提供商终端用户群的反馈表明,SD-WAN技术需求强劲,SD-WAN可以减少企业网络资本支出的部署和管理(capex)和运营支出(opex)。 Futuriom的新SD-WAN详细描述了增长报告SD-WAN工具、平台和NaaS预计2019年市场规模将达到10亿美元,到2021年可达到25亿美元,复合年增长率为35%。
思科和VMware在过去的一年里,主要的网络运营商嗅到了潜在的增长机会SD-WAN市场进行了重大收购(思科以6.1亿美元收购)Viptela,VMware以4.5亿美元收购VeloCloud)。同时,少数私营企业SD-WAN收入似乎达到了1亿美元。
战略上已经落后于这个市场。像诺基亚,爱立信和Juniper这样的网络运营商似乎缺乏全面性SD-WAN战略。而且大部分服务提供商只是简单的转售初创平台来应对SD-WAN对MPLS以及专线业务的影响。
市场内部在收集和分析行业数据后,Futuriom预计该市场的增长速度将比去年快。在调查终端用户和供应商时,发现SD-WAN由于收入基数相对较低,2018年和2019年的最大增长率正在加快。这种收入突然增长的原因有几个,包括:
MPLS带宽疲劳:企业在保持低成本的同时,努力跟上带宽需求。
云加速:迁移到云迫使企业寻找新的WAN系统架构并直接转向企业云应用。
技术成熟度:市场已经调整和改进了几年,以满足客户的需求。
企业IT驱动虽然企业带宽向云需求的转变是为了实现新的SD-WAN系统架构的重要驱动力之一,但有很多IT这一趋势也得到了加强。这些趋势包括:
带宽需求和成本升级:数据显示,越来越多的企业对宽带和网络连接电路的需求越来越大,对100不满意 Mbit/s,千兆以太网已成为企业的新目标。云和互联网通信应用 ** 这一需求。企业发现MPLS而且专用电路很贵,所以他们正在研究使用安全的互联网连接来降低管理带宽的成本SD-WAN解决方案。
以云为中心的企业:许多企业终端用户通常通过互联网直接访问云,以访问他们的应用程序。然而,传统WAN该架构通常旨在将流量传回企业数据中心,这将产生不必要的费用。新的SD-WAN软件和硬件架构可以利用互联网创建云应用程序的快速路径,包括安全性、与开放云标准和平台的互操作性、应用程序的可见性和服务质量。
网络移动与全球化:CIO和IT经理正在寻求更多的灵活性,将分支机构与软件驱动模式连接起来,使分支机构和办公室能够快速启动和运行,这需要复杂的网络配置。 SD-WAN该方法提供了从云中驱动配置的能力,加快了分支机构设备的安排,以更低的成本更快地连接分支机构。
对IT速度和敏捷性要求:企业的新需求(应用和网络需求不断变化)对能够满足业务需求的灵活网络提出了新的要求。 SD-WAN该方法可以通过基于软件的设计和配置来提供管理和规划网络需求的能力。
这么广IT网络趋势将应用程序推向云,网络专业人士正在寻找他们的云解决方案来建立、管理和优化企业网络。
SD-WAN的昨天SDN概念已经提出了十多年,转向控制的思想已经深入人心,并延伸到其他领域:软件定义广域网、软件定义存储、软件定义边界…任何技术的提出和实施都是以解决用户痛点为导向的。经过概念炒作的泡沫期,技术开始沉淀,趋于务实。
与LAN和MAN不同,WAN在更大范围内完成互联,Internet它是最大的广域网。对于许多地方有分支机构的政府和企业单位来说,有远程互联的需求。为了安全、延迟和带宽保证,租赁运营商经常被采用SDH/MPLS专线方式。
实现了专线接入VPN甚至物理隔离也在网络层面提供了自然安全和充分Qos该机制保证了对延迟敏感的应用(视频会议,VOIP等)可靠传输。但是专线也存在成本高、开通慢的缺陷:当地有没有POP点、到达POP是否有物理线路、跨运营商线路租赁与协调、各分支线路和业务逐步部署。而传统的专线网络模型又增加了企业在专线费用方面的经济负担。
云网联-传统专线网络模型(图1)
如图1所示,由于安全和审计需要,所有分支通过专线到达总部,通过总部的互联网出口进入Internet。虽然陆续出现WAN通过优化流量,加速技术(如协议优化、连接重用、数据压缩等)得到了一定程度的缓解WAN链路带宽的需求,但随着企业的需求,IT不断扩大基础设施,WAN链路带宽仍需不断扩大。
对业务可靠性要求高的企业往往租用多条运营商线路进行冗余备份,带宽利用率低。为了应对突发流量,一些企业不得不提供满足峰值流量的资源环境,这些资源大部分时间闲置,无法动态返还。这些都与云时代的资源池和动态扩展思想背道而驰。随着云计算的发展,企业IT结构的巨大变化,传统的DC云构成企业私有云。企业的IT资源或全部迁移到公共云(经典网络//VPC),或者私有云和公有云混合部署同时考虑数据本地化和资源弹性,但无论如何都必然决定正确Internet访问从以前的伴随需求变为刚性需求,数据的同步、备份和迁移也变为正常。
大量公网流量继续走专线显然不合适,所以WAN形式发生了变化—Hybrid-WAN。如图2所示,访问总部DC或者私有云的流量继续走专线,公有云的访问直接从分支进入Internet。
图二 云网联 - Hybrid-WAN网络模型
互联网转移了专线流量,减少了专线的流量负荷,但也引入了安全和保密的需求。防火墙和安全策略最初只需要部署在总部,但现在需要部署到分支机构CPE安全区域的边界从总部扩展到分支,同时需要引入相应的加密传输机制,以便在不安全的公共网络上安全传输企业内部数据。
互联网链路弥补了专线的不足,通过防火墙的安全隔离使分支机构CPE内部有一定的安全保障,SSL/IPSEC又保证了企业私人数据在互联网上传输的安全,Hybrid-WAN看似完美,但在实际应用中却暴露出一些明显的问题:
1.分支业务无法快速开通需要配置分支开通CPE业务,无论CLI或网络管理,都需要逐一配置业务,业务变更对大量分支机构的维护将是灾难性的。
2.基于路由的选择策略无法动态感知应用道路选择策略通常是根据流量目的粗略区分到总部或公共云。如果检测粒度没有上升到应用程序级别,则无法考虑应用程序对链路质量的需求。
3.战略模型过于刚性,不适应业务动态变化云计算的最大特点是高度动态。传统通信设备上的战略模型严格依赖配置。业务或链路质量的变化往往意味着配置应遵循变化。
于是WAN又出现了SDN时代的重大演变—SD-WAN。SD-WAN通过统一的中央控制器,继承了转控分离的思想CPE统一控制设备。新开CPE可通过Call Home自动连接控制器下载配置和策略,真正快速打开零接触,只需在控制器上修改一次,所有分支站点自动同步。通过CPE基于探针的流量深度识别和链路状态检测,使流量选择策略更加精细灵活,实现和网络质量的随机性,是动态流量调度的真正意义。
SD-WAN它减少了企业在专线使用中的成本。使用成本较低、开放方便的互联网也适应了企业使用公共云和混合云的技术需求。快速部署和动态调度将这种成本性能推向了极端。SD-WAN此功能不止此,但此功能是目前最具客户价值的。
SD-WAN的今天采用SD-WAN通过廉价的技术,企业可以使用技术Internet获得类似专线的特点,更适应业务云的需求,提高网络的敏捷性和鲁棒性。本文继续关注混合WAN场景简述SD-WAN实现特点和技术
云网联SD-WAN
计算资源池化构成云计算,SDN由于网络服务具有弹性伸缩、按需服务、快速部署等功能诉求,其目标可视为网络云化。SD-WAN将广域网链路抽象成资源即虚拟Overlay为业务提供服务,屏蔽底层链路的具体形式,帮助业务快速获足需求的资源。从SD-WAN实现大致可分为三类。
1.传统设备制造商加入传统网络设备SD-WAN功能,对于CPE或总部出口 ** ,根据预配置策略,通过到目的端的链路检测协议,检测链路负载、延迟、抖动和丢包率,选择满足业务需求SLA路由需求链路。例如,向控制器发布以下策略:
1. 视频业务A需要选择时延小于20ms的链路
2. 剩余带宽大于10M的链路
根据控制器的策略,设备识别应用A和B,选择合格的链路进行转发,并根据链路质量进行动态调整。另一种常见的策略是负载分担,可以根据链路负载动态修改选择,最大限度地利用链路资源。
云网联-面向应用的多出口选择(图1)
对于这种场景,没有保密要求的业务直接进入SP网络需要通过隧道进入加密传输业务SP这种隧道可以被视为网络P2P的Overlay,但是,无论以何种方式流量进入流量SP后来失去了控制,由Underlay传统路由网络。SD-WAN企业自行部署服务,可控性更强,但由于Internet有时可能无法选择流量的突发性和不确定性来满足需求SLA企业需要提供多个链接。
1. SD-WAN服务商以Viptela、 Velocloud为代表的SD-WAN提供软件的服务提供商(NFV)或者通过租用设备的接入方式SP在Underlay在网络上建立一个多个网络POP点组成的Overlay逻辑拓扑。如图2所示,用户边缘SD-WAN设备就近接入POP,通过应用识别和链路检测,采取与上述相似的策略Overlay逻辑网络选择满足业务需求的路径进行路由或综合Overlay和Underlay进行选择。由于POP网元较多,使了网络的可控性和可视性,往往很容易选择符合条件的链路。服务提供商使企业无需部署控制器等服务,用户只需定义战略模板即可实现,减少了企业的使用SD-WAN技术要求。
面向应用的Overlay路由(图2)
1. 运营商运营商有直接在场Underlay网络上提供SD-WAN服务条件,基于传统路由实现战略和业务的路由,但由于意愿和部署困难,这个想法可能只是一个想法。
SD-WAN功能特性多,混合WAN场景,软件定义功能的分支CPE满足以下业务需求:
1. 主动回连控制器获取配置和策略传统组网的CPE设备高度自主。无论是命令线、网络管理界面还是制造商实现的所谓零部署功能,它仍然面临着孤立的网络元素和配置驱动。业务模式的变化意味着分支网站需要修改配置。SD-WAN同意转移控制分离,业务配置和策略由控制器发布,使用户界面从面向配置到面向应用,实现真正的即插即用。Netconf是SD-WAN这是一个典型的南向协议,是一个典型的南向协议C/S采用模型协议SSH或TLS作为安全通道,YANG控制器作为元数据完成命令描述的定义Client将上层的REST调用依据YANG定义转化为承载NetConf中的XML-RPC,作为配置设备Server根据YIN校验RPC合法后转为最终设备配置。
2. 深度识别应用应用程序的前提是能够识别应用程序。基于5元组的传统流分类和路由策略过于刚性, 并且需要大量配置逐一匹配应用,界面不友好。SD-WAN在场景中,设备需要深度 度检测,通过本地识别或是云端识别归类应用,依据控制器策略进行流量的动态调度 和关键业务保障。
3. 链路的质量检测传统基于路由的流量调度是静态的,网络环境却是实时变化的,无法依据链路质量的变化动态调整,SD-WAN场景下要求设备能够针对多条专线或互联网链路进行质量检测,按照业务分类和控制器下发策略对流量进行动态选路。
4. 防火墙功能分支接入互联网,分流了专线流量,就近接入公有云获得了更好的使用体验,但同时安全问题也被引入进来。分支CPE需要提供安全 ** 功能,划分安全边界,清洗非法流量,防范黑客入侵。防火墙功能可在本地完成,也可在云端通过虚拟化实现。
5. 加密VPN连接企业数据在Internet上传输时为了防止泄密需要采用安全通道传输,CPE需要能够与公有云、总部或其它分支VPN ** 建立端到端IPSEC隧道,流量通过IPSEC隧道加密传输。
6. NAT功能对于无需加密的Internet流量,进入互联网时需要做NAT转换,解决了公网地址资源有限,同时也实现了内部地址的隐藏。
7. 鉴权和审计传统组网出口全部在总部,鉴权和审计功能可以在总部单点部署,SD-WAN场景 下的鉴权审计也变成了分布式,要求每台分支的CPE设备具有相应的功能,且能将数 据日志定期回传同步。
SD-WAN可以采用专用硬件或VNF编排实现,只要符合集中控制、弹性伸缩、动态可编程的思想都可以划归到软件定义范畴。SD-WAN不是概念,是使用软件思想重新思考网络的必然结果,是能够完成网络重构切实解决用户高频痛点的有效技术。
3. SD-WAN总体方案设计SD-WAN的必要性SD-WAN也就是软件定义广域网,它是软件定义网络(SDN)技术在广域网(WAN)中的一种特定的应用场景,广域网连接主要用于连接包括分支机构和数据中心在内的企业网。
从上述角度来说,我们认为的SD-WAN至少要受到两个主要变量的影响:SDN和WAN。SDN(软件定义网络)诞生10年,目前已经在业界开始实践落地,SD-WAN作为SDN在WAN中的应用,我们认为需要满足SDN的特性,即需要集中控制;也需要满足WAN的特性,即连接性。
Gartner在2015年发布的报告认为,SD-WAN相对应的是传统的基于路由的广域网,或者延伸一点说是基于硬件设备连接的广域网。 ** 上给的定义是SD-WAN是一系列技术的,主要概念是将SDN的技术应用在广域网。软件定义网络技术使用虚拟化技术,简化数据中心的管理及运维的工作,同时也可以将相关技术应用于广域网络之上,可以简化企业级用户对于广域网络的控管。
通过SD-WAN,公司可以用低成本的网络构建方式建立起高效能的广域网络。企业因此可以部分或完全替换掉昂贵的私有广域网络技术,例如MPLS。
WAN遇到的问题
WAN作为企业的连接方式,在过去的数十年中持续为企业提供服务。随着企业的数字化转型和业务多样化的需求,以及数据大爆炸的影响,目前的WAN中传输的流量已经造成了WAN不堪重负。
广域网接入节点分布广泛、数量众多、部署周期长、维护难度高
传统网络技术僵化,难以满足业务敏捷性的需求,尤其是随着企业云化的需要的增长,
WAN难以满足云计算的发展需求:
广域网带宽与性能需求迅猛,成本压力逐渐提升
l 缺乏对WAN流量的可视化监控和管理
l 传统的WAN性能相对比较固化,难以实现对WAN的优化,即便能够对WAN进行优化也很难具有成本效益。
为应对企业多样化的网络连接需求及对性价比的追求,SD-WAN的概念在2014年被正式提出,并在诞生后的三年内迅速升温。根据Gartner的报告,2016年只有1%的企业部署了SD-WAN,但预计到2019年底,部署SD-WAN的企业将会增长到30%。
l 快速配置:传统的MPLS CE设备需要专业的网工才能完成客户侧的配置,而理想的SD-WAN 客户侧设备更像是一个消费级电子产品,假设用户都是非IT工程师,只要接上电源线并做一些基本的配置就可以实现网络通达和优化。这些基本配置可能都是采用普通消费者可以理解的日常语言来描述专业的网络功能。而为什么SD-WAN可以做到这个呢?其中一个原因是整个消费电子的进步,另外一个决定因素是网络大部分的功能都在云端,所以真正在CPE上且需要用户去参与配置的功能就会很少。
提高可靠性:相信在SD-WAN的产品初期,可靠性依然不是很强的,但是SD-WAN将网络功能集中化的一个好处就是CPE上的功能会很简单,更复杂的网络功能都在“云端”,所谓的云端就是提供商的控制器,而简单必然会带来可靠性的提升。
提升性能:因为SD-WAN可以针对用户的需求有针对性的优化链路质量,比如用户需要提升访问office365的体验,只要建立用户CPE到office365云端的专用链路,即可以提升office365的使用体验
降低成本:通过利用零接触配置和自动化,组织可以节省硬件、软件和IT资源,尤其是在分支机构尤为明显,此外,很多企业可以通过采用混合广域网的模式来节省成本。
SD-WAN总体网络架构规划设计三种不同场景的SD-WAN的部署案例,包括:SD-WAN接入-基于Internet Edge解决方案,SD-WAN骨干网-基于SRTE 流量调度的Core解决方案,以及基于多厂商WAN的SDN协同控制器或业务协同编排器。这三个场景比较有代表性,也是目前遇到的典型的SD-WAN的需求
第一类部署场景:SD-WAN接入服务 ,也是最典型和最通俗的场景,有时也称为SD-WAN Edge 解决方案,运营商可以用这个技术作为MPLS互补或下一代MPLS替代,企业可以利用这个技术实现分支机构按需组网。
市场需求情况:随着企业上云和广域网按需接入的需求日益增加,传统的MSTP和MPLS等专线业务由于成本和部署周期长等问题已经难以满足云和互联网时代的需求,面向基于互联网和POP路径选择的SD-WAN是技术随之诞生,这是一种面向分支灵活接入的SDN-WAN 部署场景。由于目前国内运营商MPLS VPN网络的已经大规模部署,短期内运营商不会用SD-WAN替换MPLS或其他专线业务,但是会利用SD-WAN技术丰富MPLSVPN业务或者做为最后一公里的接入技术。
主要的技术实现:其实SD-WAN在技术上没有本质上的革新,但SD-WAN在理念上有了新的突破,融入了SDN控制思想结合POP线路SLA探测技术,同时可以实现云网一体的协同部署,技术实现如图所示 :
SD-WAN通用技术及通用功能不在这里赘述,这里从实际部署的角度谈谈几点考虑:
1)在SD-WAN设计和部署时,在中国需要考虑南北运营商Internet瓶颈的问题,客户部署设计时会选择在多个机房部署多线POP节点,在每个POP节点部署vPE设备,各个POP节点的vPE 通过专线组建骨干网保障SD-WAN汇聚上来的流量SLA,在这个案例中 POP节点的vPE 通过客户的MPLS PE节点来组建(在其他项目中我们采用SRTE作为骨干网流量调度)。在一个大SD-WAN部署时,每个CPE会根据控制器的下发列表探测并选择最佳的POP节点,并连接最佳运营商线路的vPE,在SD-WAN设计时Edge和Core都需要考虑线路的SLA保障,再利用SDN控制器的部署全网统一的路由,安全和QOS的策略部署和控制,从而解决基于Internet接入服务质量问题和全网统一策略部署问题;
2)另一个要解决的问题是SD-WAN的租户如何与现网的MPLS租户对接(租户分支机构有可能是SD-WAN线路,有的是MPLS专线混合组网),前面提到目前几大运营商基本上都已经有自己MPLS网络,SD-WAN与MPLS VPN的对接是必须考虑的问题,我们在PoP点的vPE如何与 MPLS PE节点实现自动化对接上有多重方案可以实现,包括纳管PE, Option B,Overlay等等,
3)对于CPE的自动部署与传统路由设备包括线路之间的的备份和负载分担也是SD-WAN能否成功的关键因素,由于现在多数厂家的SD-WAN 控制器与 CPE盒子是紧耦合,导致后期被厂商锁定,因此有几点建议考虑:如CPE盒子是否支持OpenWRT? 小盒子 ZT-PnP自动部署机制如何(防火墙穿越能力)? CPE如何自动选择延时最小或带宽最佳的接入POP点? 能否做到即插即用、自动连接、自动切换。
4)对于整个系统的核心是SDN控制器,控制器的可靠性、集群、租户自服务管理 和易用性也不可忽视,作为一个运营商通常还需要 SD-WAN 控制器的北向与现有的BSS/OSS对接集成也是要考虑。 虽然SD-WAN没有大的革新技术,但一个完整和成熟的SD-WAN方案技术上也不简单,SD-WAN带来的部署运维简单易用是明显的,而且企业不再需要专业的CCIE人员设计和运维,对于分支机构的扩展和部署,传统的MPLS部署可能需要几个月,而现在理论上分钟级就可以了。
第二类部署场景:
面向服务商和大企业的SD-WAN核心骨干网调度(包括DCI),典型场景:大型运营商 和OTT客户的SD-WAN骨干调度(包括DCI), 大企业 SD-WAN核心骨干网。
代表客户案例:
Google B4的商用部署 SD-WAN经典案例项目(2012年 发布)
2018年2月中国工商银行发布基于MPLS骨干网的SDN部署
主要的市场需求:SD-WAN骨干调度核心思想是流量调度和基于多租户的服务和管理,有时候我们也称之为SD-WAN DCI/ Core解决方案,这个方案和前面提到的基于互联网的SD-WAN Edge在功能和定位截然不同,但两个方案定位互补。
主要的技术实现,目前主要有三类方式:第一类基于白牌机+Openflow SDN控制器-Google B4就是基于这个方案(2010-2012年),Google B4的核心是它的TE调度和算法而且它巧妙地避开了Openflow的众多缺陷,包括基于源和目的地址配合DSCP作为流表的转发策略,但项目其关键技术细节(如SDN控制器平台算法)即不对外公布,也不对外销售,后来者虽然有模仿但也很少能超越,除了Google,我说了解到一些客户对这个组合方案反馈还是有些问题,包括白牌机对 SRTE 支持能力 、 BFD/Tunnel 支持性能和数量 , 路由策略和VPN能力 ,交换机流表和端口缓存的大小 等等,毕竟是交换机的方案也不能勉为其难,更何况连Nick McKeown 现在又转向主导的可编程语言P4并创立Barefoot Networks;当然目前业界有一种新的思路基于白牌机的Overlay方案,利用vPE配合白牌机来解决上面提到的问题,vPE与交换机互补来实现流量调度和路由策略等功能,由于篇幅问题这里就不在展开讨论;
第二类有基于 MPLS +SDN控制器实现全网的流量调度和VPN租户管理- 类似工行SD-WAN骨干网(2017发布),MPLS TE多年前就有在部署,就目前运营商客户部署情况看,绝大部分抱怨MPLS TE的部署过于复杂因而真正在生产网TE隧道使用的并不多,由于MPLS成熟有余先进不足,这里就不想过多的赘述 ;
第三类方案也是笔者更希望看到的,是基于SR(Segment Routing)实现流量调度和管理SR+SDN控制器,和MPLS的网络类似,但是SR可议基于源头组建一个完整的LSP Path而且和现有的MPLS网络可议兼容, 因为SR也是以标签交换为基础的, 只需要对现有的IGP协议进行简单的扩展,就可以实现TE、FRR、MPLS VPN等功能, 包括流量工程TE的自动下发、自动计算、自动调整、自动引流和自动调度。
UniWAN
基于SRTE的SDN控制器目前在业界属于非常领先的技术,SR的基础转发表甚至比LDP更简洁,利用了源路由技术与SDN理念完美结合,在流量TE管理方面,SRTE比RSVP-TE状态少很多,也不需要LDP/RSVP信令那么复杂。但是目前各个硬件厂商(包括第三方控制器+SR路由器)在SRTE具体实现还是有一定差距, 但有几点是部署时需要考虑的:如何根据链路质量(load/loss/delay)动态实时调整TE路径以实现全局负载均衡、隧道快速倒换策略和逃生算法(如思科PS技术)、配置回滚的一致性、离线流量规划、TE路径的对称故障检测等等,各家方案功能差别很大, 在国内能真正完整实现基于SRTE的SDN控制器更是屈指可数。
第三类部署场景:基于多厂商的SDN协同控制器或业务协同编排器,目前大型运营商和OTT客户和超大企业在SD-WAN多厂商异构环境下已经开始考虑。
代表客户案例:2018年3月 中国联通宣布”国内首个大型运营商云网融合商业SDN成功上线(基于联通A网的 SD-WAN DCI系统)”
主要的市场需求:在前面两大类SD-WAN在部署时,客户往往需要多个厂商设备实现一种平衡,客户是不希望被厂商锁定,但目前多数SD-WAN的网络还是封闭的管理系统,基于多厂商的SDN协同控制器或业务协同编排器是一个难题,互操作和资源统一管理问题是需要上层SDN协同控制器来解决,这类解决方案对大型SDN网络运营尤其重要 。目前几大运营商和OTT行业都意识到或开始考虑这个问题,相信将来企业客户随着SDN部署也会有类似需求。
主要的技术实现:以某运营商为例,两年前开始预研云环境下MPLS骨干网多厂商控制器协同工作问题,经过近两年的设计、研发、和联调等各个环节的艰辛努力,该客户成为国内首家在全国骨干广域网上实现云网一体化服务的运营商。 同时,也开创了在国内大型SDN项目中,选择独立的核心SDN软件企业与多家大型网络设备厂商通力合作,以确保运营商能够全面主导、把控SDN运营需求和技术架构方向及决策话语权,为最终云网一体化产品按时商用上线提供了一个成功案例。但是多厂商的协同控制器需要根据客户的业务实际情况来定制开发,需要SDN软件厂商有非常强的研发能力和行业经验,包括对厂商硬件的北向接口规范、云网技术的深入了解(如 VX等)、主流公有云系统的对接、以及和客户OSS/BSS业务系统集成等,实际做起来是非常的复杂,不是一般的SDN玩的起的。 如图所示,随着SD-WAN多场景和多厂商的部署越来越多,多厂商的协同管理和统一编排将成为未来SD-WAN的重要话题。
UniWAN
SD-WAN分层网络规划设计下面我们看看有关SDN的两个具体技术:VXLAN和Segment Routing。目前看基于VXLAN的 BGP EVPN已经成为云数据中心网络标配技术,VXLAN可以为数据中心内部或数据中心间大二层网络,为虚拟化、集群和云的部署提供Overlay的网络,由于VXLAN基于传统的L3网络,充分利用Underlay Network 网络的稳定和可扩展能力,而且目前主流厂商甚至白牌机都已经支持,早期还有OTT客户想基于Openflow部署,但由于Openflow的Scaling问题,最终基本上都选择了VXLAN-EVPN的解解决方案。
另一个技术Segment Routing能否作为未来广域网重构的关键技术,仁者见仁智者见智,但我认为在广域网基于SR-TE的广域网SDN的解决方案前途不可估量; 一方面源头路由控制最适合广域网SDN,另一方面SR TE解决了传统WAN流量调度的难题(MPLS TE由于太复杂即使在运营商也一直没有大规模部署), SR可以在独立提供FRR保护, 提供快速重路由保护也是传统MPLS网络的难以媲美,当然有一个话题,在数据中心内是否可以用SR替换VXLAN,是一个好问题,但目前看还有一定难度或难以替换。
SDWAN广域网重构实践分享接下来我们介绍第二部分:SD-WAN广域网重构实践分享。这个话题比较大,我们从两个维度看看业界SDN的发展:一个维度是SDN可以适用在什么场景,一个维度是哪些行业可以使用SDN。首先看看第一个维度适用在什么场景,基本上企业(包括运营商、OTT或大企业)分支,骨干网和数据中心三个场景都比较适合。比如现在运营商在谈E-Cord解决方案,实际上就是基于SDN+Openstack实现端局云化,在骨干网基于SDN的流量调度和多厂商管理是个非常大的热点,尤其是基于SDN+Internet广域网接入如何解决”最后一公里”或南北运营商服务质量的难题, 在云数据中心尤其是公有云、托管云等SDN早已被采纳和部署。 对于第二个维度行业维度,在SDN部署走在前列的是OTT客户和三大运营商,国外Google最早开始部署SDN的网络,OTT客户在公有云、托管云方面明显走在业界前列,三大运营商由于一般都有1-2张的全国性的骨干网,对于SD-WAN的热度明显高于一般行业。最近在拜访的一些大企业客户中,也已经把SDN的规划列入未来几年的发展重点。如下图所示:
对于SD-WAN的一些应用场景,这张胶片介绍了几种典型场景,如下图所示:
包括企业到企业分支internet或专线-最后一公里问题,企业到公有云和托管云,企业到数据中心,公有云到私有云和托管云。 他们的共性都是基于SDN做统一的控制和管理,包括设备自动部署,路径调度,隧道选择或加密,流量的可视化和服务质量保障,基于租户的管理等等。就像这张基于互联网应用场景动画,企业应用可以放在数据中心或放在云端,分支机构可以基于互联网或MSTP专线接入,但SDN控制器作为全网络的调度和管理中心,为企业提供企业分支快速上云,访问云服务。
下面分享一个某服务商骨干网重构SD-WAN项目案例,如下图所示:
云网联
客户需要部署多厂商异构环境下SDN控制器和业务编排器,目标是简化运维,提高与公有云业务对接,实现分钟级业务部; 在这个项目部署中,在异构系统、多厂商网络的SDN管理是个世界难题, 国际上没有先例可以参考,大地网络团队和客户一起攻破史无前例的技术难题,成功实现独立于厂商设备的SDN统一调度控制器,实现骨干网络业务分钟级快捷业务服务,实现统一的APP和业务编排层,屏蔽异构厂商细节;SDN系统的北向南向统一标准API,可以开放给第三方APP(如OSS/BSS等), 南向可以实现异构厂商控制器的HA和数据同步和资源统一管理和调配。该系统帮助客户实现基于SDN的商用骨干网重构,实现业务层与网络层解耦,同时网络层兼容多厂家设备 实现云网一体化的SDN统一调度控制,实现骨干网络业务分钟级快捷业务服务等。
下面介绍一个典型 Segment Routing在SDN环境下的部署案例(参考思科的SR技术文档),如下图所示:
UnIWAN
骨干网的PE/P设备注册到SDN控制器,PE/P设备BGP-LS将网络节点和拓扑、链路状态和带宽、现有TE隧道的能力、时延/丢包等信息传递给SDN Controller ,由Controller完成选路,并将选路信息下发给路由器,从而避免分布式TE计算的问题, 一个包进入网络入口时,基于Source routing算法标签栈已经确定,SDN Controller对外提供统一的用户UI、流量监控接口、网管和业务层面的北向接口。
硬广时间到: 关注我们的公众账号免费试用我们的服务。
>weixin.qq.com/r/Tymnv7jE3_Wgrfzc93xd (二维码自动识别)
UniWAN公众账号
本文版权由“北”所有。
未经许可禁止转载