老网工:浅谈云网协同下SDN设计的思考和实践

作者简介:杨文斌,网络通信与安全紫金山实验室专家;大地云网技术总监

这些年网络在悄悄的改变

记得刚入IT这一行的时候,网络刚刚兴起,网络作一个神秘和高大上的技术让无数IT人羡慕,如今随着混合云和多云互联时代到来,网络再次成为业界关注,但是今天提到网络已经不仅仅是传统意义上的路由器交换机的Underlay网络,更多是基于租户的按需提供服务的Overlay SDN网络。在当今云的环境下,计算资源按需提供服务能力,秒级开通已经不是难事,但相对于网络的按需服务和自动化部署还是有一定的挑战,尤其是异构网络环境以及混合Overlay环境,在多域环境、多云互联如何实现云网协同,SDN网络该如何设计和部署,目前已经成为中国运营商、线商、云商及大企业非常关心的焦点话题。(有人也称之为”云网一体或云网融合”,作者更喜欢用”云网协同”一词)。作为一名还在奋斗在一线的老网工,最近参与了一些运营商和云商的大型云网SDN协同管理平台项目的设计和建设,今天围绕这个话题跟大家做一个分享。

围绕SDN讨论已经很多,尤其是SD-WAN的出现,在云商、运营商和线商, 掀起了非常大波澜,大家开始捕捉到了很多新的商机。云商由于业务的需求最早在云中心内以及DCI骨干节点间的采纳SDN技术满足云网协同和流量调度需求,这些年随着SD-WAN的出现,快速上云、把云业务延伸到客户分支以及为客户组网为云商及服务商带来了新的机遇。 在这个背景下传统的大型运营商业务压力越来越大,好在运营商拥有无可比拟的全国运营线路资源和客户资源,这些年开始大刀阔斧调整云网战略并加大对云网协同技术的投入和重构现网资源,为客户提供上云和联云的一站式服务能力,虽然运营商起步稍晚,但是线上线下资源多,实力雄厚,起点高,提供从最后一公里到云端的端到端的云网协同能力强。

云和网两大技术引擎之失衡

云计算的本质就是网络计算,云计算通过网络平台的横向能力打通逻辑计算资源池和实现资源按需调度和平衡负载的服务能力,计算和网络作为IT双引擎叠加协同成就了今天信息通信的飞速发展。但是客观讲,两大技术引擎是失衡的,今天计算资源的云化和按需调度和部署倒逼传统的网络模式改变。为了配合云计算的自动开通和秒级部署,网工们10年前就已经开始思考数据中心云化网络的演进,从早期的FabricPath/Trill/OTV 大二层到今天如日中天的基于VXLAN轻量级Overlay技术,可以说数据中心的云化网络发展相对要快,尤其是随着SDN技术的出现,基本实现了云中心内部网络按需服务能力和自动化管理,但异构网络环境、混合Overlay环境、以及多域网络环境依然有很大挑战: 客观来讲网络协议多和技术复杂导致端到端网络自动化部署和管理的难度,一方面网络会牵涉多域的协同配合:除了数据中心网络,还要考虑骨干网络以及边缘接入网络,多域的协同配合和网络服务能力是今天SDN的一个焦点;另一方面网络相关的协议或技术非常复杂, L2/L3/GRE/VXLAN/EVPN/MPLS/SR/OF/ Netconf/Yang/Neutron/ODL/ONOS协议或技术数不胜数,再加上QOS/加密/FW/NAT/流量调度/TE隧道技术等,这年头做一个好网工实在是不易,设计一个大型云网协同SDN网络更不易。 如下图所示:

云网架构对SDN的诉求

云网协同的SDN网络架构设计,需要满足云内网络、云间互联和上云网络的需求,需要管理复杂的多域和异构的多个网络资源系统,实现云网业务的协同工作和一站式管理服务。由于云网协同架构涉及的内容较多,各行业需求不尽相同,目前国内大型运营商、云商以及OTT公司在这个领域的规划和部署相对比较超前,以运营商、云商和线商为例,简要分析一下云网协同对SDN设计的主要诉求:

云内资源池的统一管理需求

多虚拟化资源池(Openstack,Vmware,K8S..)、物理资源池如何统一协同纳管,异构网络设备如何统一纳管, HostOverlay和HW Overlay网络如何选择或混合组网问题? 以及云和网的资源管理和监管等。

多域网络系统协同调度

这是大型服务商会碰到的问题,云化网络涉及多个网络域,包括:骨干网有云联网、边缘接入网络SD-WAN、云中心内部的网络系统以及多云互联网络系统(内部云资源池网络,合作伙伴云系统),多个域用到截然不同的网络技术,如何通过SDN云网协同技术实现适于跨域部署的云资源布局,让用户可以一点接入、多点部署、全网服务。

网协同网络服务能力和标准规范

大型的服务商希望自己制定API规范和Yang模型重构云网协同架构,规范多域网络资源的管理以及云池对接的接口规范和标准,这个思路非常好,但是对网络厂商提出了更高的要求。但现实中各个域网络功能不同和厂商的接口规范不同,如何打造统一的云网协同网络服务能力给业务平台统一调用也是一个有趣的话题。

云网协同架构下SDN的设计

云网协同架构下SDN的设计涉及面很多,需要考虑从接入到云的多域之间的端到端的租户VPN自动打通,对不同域的网络资源纳管和协同部署,以及端到端的线路SLA探测和流量调度, 还包括分权分域的管理能力。在2019第二届中国SDNLAB峰会上,作者分享了《云商、线商和运营商如何成为SD-WAN时代的赢家?》,其中谈到SDN设计话题,首先它是网络技术属性:在传统网络中,传统厂商如思科对网络基础技术如路由策略、服务质量、安全性做的非常好;但是SDN作为一项技术革新和管理模式的革新,SDN/SD-WAN设计里面必须构建在稳健的网络基础功能能力上,同时需要更多SDN的属性和抽象服务功能, 笔者认为云网协同架构下一个好的SDN的设计归纳起来有三个点一定要设计好,今天就重点谈谈这三个设计点:

SDN南向协同器适配层设计

SDN协同器模块是负责全程网络资源的统一收集、抽象和组建,实现网络资源和能力的模型化,是SDN网络编排平台能力和服务支持的基础组件。SDN协同器南向对接:Openstack平台、骨干网控制器、SD-WAN控制器 、数据中心网络设备控制器以及第三方云平台等。

针对SDN协同适配层,我们的建议如下:SDN协调器实现物理网络向逻辑网络的转化,为物理网络资源提供统一的网络服务能力抽象,整合异构厂商设备并实现解耦,这是SDN网络设计好坏的根基。多域涉及多种网络设备和技术、多种厂商的控制器、 不同厂家定义的YANG model、命令内容、配置方式, SDN设计师必须掌握多领域最新技术的系统整合设计,并具有创新实践的能力和经验。

SDN网络业务编排器模块

SDN网络业务编排器模块依赖于SDN协同器所提供的统一网络抽象、逻辑网络和网络资源模型,提供业务平台所需的所有网络服务的基本机制和管理。网络服务的基本机制包括基于租户的VPC网络路由、基于租户的VRF虚网和路由、云数据中心内2层VPN和3层VPN,BGP/IGP 路由,SD-WAN的接入和SD-Core骨干整合 ,流量工程和SLA服务策略和安全等等。SDN业务编排器将网络资源和能力抽象成统一的业务模型,提供给云业务平台, 业务层无需感知任何底层厂商设备细节,完全解耦。 针对统一业务编排模块,我们提出了2点建议:

  • 业务编排器整个系统架构按照业务和功能进行拆分,建议基于现有成熟的微服务架构实现最小粒度化的服务模块。微服务可以按需组合完成各类业务场景开通,实现完全解耦的模块化系统架构设计。
  • 统一业务编排器的设计需由具备既熟悉网络的底层架构、技术和协议,又掌握新型云网络技术和软件架构的全栈技术的专业架构师来完成,同时还需要对客户的业务与网络之间关联关系有深入的了解。

SDN网络业务北向API规范

云网协同SDN架构为数据中心、私有云、公有云、分支机构提供了端到端网络接入服务。API规范和Yang模型不仅要满足网络资源的管理和对接,还需要和多个云平台打通并对接,适配多域网络系统、多云平台等可编程平台,供北向业务系统统一调用,为用户提供云网一站式打通。由于云商和运营商的API业务流程和调用流程服有很大差异,跨域部署的网络架构和多云资源布局差别很大, 做好SDN 网络编排的API规范的技术难度也非常复杂。针对API规范,我们的建议如下:

  • 云商对接须尽早进行:大部分云商都有各自非标准的API规范,且每个云商的接入方式、路由设计以及API还是有很大差别,须有经验的开发人员尽早参与讨论和设计。
  • API调用流程须协调好:比如: 在资源申请中,多域环境下是一点登录还是允许云商和服务商多点登录,一定要协调好。典型客户需要:可以让用户一点接入、多点部署、全网服务,这需要涉及跨域部署的多服务能力和多站点资源布局和统一管理。

云网协同架构下SDN的实践分享

前面分析过大型服务商的云网协同架构至少涵盖接入、骨干网和云中心等几个层面,这不仅涉及到整体架构的统一规划还涉及到多域技术整合。下面针对某客户SDN实践部署做一分享: 客户是某大型服务商客户,希望云网协同统一管理、协同工作,基于SDN技术重构网络基础架构,对接公有云和私有云资源,提供端到端的网络服务自动部署和调度(SDN业务编排), 为企业客户提供上云服务、跨云的连接(包括数据中心、公有云、私有云)和分支组网等多重场景,包括解决云计算落地“最后一公里”的问题。 这个客户是一个大型运营商的项目,在架构设计特别关注以下几点工作:

  • 从接入到骨干到云端的统一业务编排,一站式服务
  • SD-WAN 多线机房POP节点+SLA探测
  • SD-WAN POP与 MPLS PE节点无缝对接
  • 基于租户SLA业务的SRTE 流量调度
  • DCI L2/L3VPN业务自动开通,云DC内部VR到GW的自动打通
  • 组网场景:企业一线上云、企业云组网、 企业云宽带、互联网+专线混合组网等等

在架构设计特别关注以上几点,我们采用大地云网SDN解决方案(也算做个小广告)如下图所示:

下面就客户部署的情况加以详细介绍一下:

SDN编排和服务平台

我们在项目中针对客户的需求和服务流程,为客户提供了多域的服务编排能力,对接公有云和混合云互联的业务编排, L2/L3VPN网络业务编排,SD-WAN接入云和骨干网整合业务编排, 通过我们的编排和服务平台提供端到端统一调度资源、SLA服务质量保障、路径规划和VPN租户安全管理,同时提供从边缘到骨干以及与各家云商对接的多域业务的统一北向API规范和YANG模型,实现异厂家控制器对接和解耦。 大大简化了传统的客户业务系统需要调用多个网络域的烦恼( 屏蔽了南向各种复杂的网络资源和接口规范的差异性),为客户业务中台提供了云网协同能力奠定了基础。由于客户的业务需求、环境和流程比较复杂,我们基于大地Terra业务编排器并做了大量的定制开发。同时我们在Terra业务编排协同层纳管了SDN数据中心控制器,SD-Core骨干网控制器和SD-WAN边缘接入控制器。

云数据中心网络

我们重点考虑以下几点:在云中心考虑云资源池的VPC的网络与物理资源池BM网络部署了混合Overlay组网,包括Openstack Neutron联动。第二个是由于客户有招标要求,在不同的POD区采购了多厂商的网络设备,如何管理多厂商的VXLAN/EVPN 网络,为上层提供统一的逻辑网络服务能力; 第三个重点设计考虑VPC与外部网络尤其是骨干网的协同管理,实现VPC和边界路由器(GW/VBR)互通和统一纳管。 客户对于异构环境传统网络厂商难以解决或不愿意解决,这都是苦活累活技术活,我们基于大地云网 TerraDC 控制器实现上述功能,并增加L4-L7的NFV服务管理。

骨干网络

我们重点考虑L2VPN、L3VPN业务的自动开通和重要业务的SLA和流量工程设计。该服务商的骨干网采用以多协议标签交换(MPLS)/分段路由隧道(SRTE)为主骨干网路由器组网,通过虚拟专用网络(L2VPN/L3VPN)与云中心以及租户分支机构对接,同时客户利用SRTE实现金银铜不同业务的SLA服务质量保障,客户采用SR+SDN重构新一代的骨干网实现流量调度和管理。 由于PE节点要延伸到数据中心和公有云,PE和边界路由器(GW/VBR)互通以及和SD-WAN接入实现自动对接也是本期重点,我们基于大地云网 TerraCore 控制器实现上述功能。

边缘接入网

在设计时重点考虑里SD-WAN PoP点组网设计和探测,多线POP节点设计和组网以及POP点如何和骨干网的MPLS整合为一体,接入侧CPE设备利用自动探测技术选择最佳的POP节点,还有一点与MPLS的整合组网要考虑如何防止路由的环路和倒灌,以及SD-WAN租户与MPLS租户的完美统一,解决MPLS解决最后一公里问题。 随着今年疫情,客户正在将移动办公融合到SD-WAN系统中。 这部分我们基于大地云网 TerraEdge实现上述功能。

结束语

新型云服务商追求资源逻辑管理和秒级响应, 传统的运营商网络或传统网络模式已无法支撑业务的弹性和快速增长。云网协同和SDN技术的出现,将整个物理网络抽象并简化为“单一”逻辑网络资源池,并通过软件定义用户业务的自动化流程,实现多个系统联动、多个域网络联动,完成业务端到端快速自动部署。这些年来, SDN网络技术作为开放软件架构受到新型云服务商和运营商青睐和认可,但在通用性、标准规范和互操作方面还有很多路要走,但不论如何,SDN和云计算作为未来IT发展的2大最基本的创新引擎势不可挡,相信不远的将来SDN与云计算相结合的云网协同将会给运营商、云商和客户带来一片新的天地。


  • 本站原创文章仅代表作者观点,不代表SDNLAB立场。所有原创内容版权均属SDNLAB,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用,转载须注明来自 SDNLAB并附上本文链接。 本站中所有编译类文章仅用于学习和交流目的,编译工作遵照 CC 协议,如果有侵犯到您权益的地方,请及时联系我们。
  • 本文链接https://www.sdnlab.com/23964.html
分享到:
相关文章
条评论

登录后才可以评论

atmywb 发表于20-03-30
8