深入理解SASE(三):什么是云网融合

本文转载自“好奇瞅瞅”

系列一:深入理解SASE(一):什么是云化
系列二:深入理解SASE(二):网络云化及演进方向

什么是云网融合

承上,云网融合和网络云化是什么关系?如果单从网络视角来看,云网融合等同于网络云化,一个是目的,一个是手段。

其次,什么是云网融合?这是一个小众领域里的热门词,大多是巨头和大佬在谈,有很多解读,凑不了这个热闹。“不忘初心,牢记使命”,我们的目标是:分析产业互联网下诸如SASE、MEC、IoT之类的产品机会,所以以下就从最朴素的视角来分析。

云网融合,字面理解就是“云”和“网”融合,没什么好特别解释的;广义理解应该是“应用”和“网络”融合,因为“云”在这个时代语境里,代表了上云的各种应用和服务。

只有这样理解,才能回答一些带刺的问题:在边缘时代,网络是以云为中心,还是以边缘为中心?预料这可能会是一个新时代下的“甜咸豆浆”问题,巨头和大佬的出身,基本决定了答案,届时可以看看热闹,选择吸收。

照着这个理解,云网融合的好手是谁?觉得反倒可能是做“云”这门生意并不成功的Google。Google贡献了一个BBR,一个QUIC,好家伙,这两项可都是旨在动互联网大厦根基的协议。一家做搜索应用的公司,把网络玩得如此通透,图啥?肯定不是为了“为他人作嫁衣裳”,而是为了极致优化它的核心应用。

再多问一下:SDN/SD-WAN算不算云网融合?初看一下,这是啥跟啥,哪里扯得到边。那么就再回归本源,多问一下:为什么要“软件定义”(SD-, Software Defined)?如果不是为了更好更快更高效地操纵网络去服务应用,要啥软件定义呢。

当然,学术派会说SDN/SD-WAN还有什么白牌化,摆脱厂商绑定等优势,嗯,没错,不过我们再来掰扯掰扯:现在有这么多控制器,哪家的控制器可以真正控制别家的设备了吗?现阶段到底是更开放了还是更绑定了?一些课题甚至早早就在考虑怎么统筹支离破碎的控制域了。

所以,在当前的产品形态下,说白了可能都还是半成品,北向还远远达不到可以形成一个AppStore之类“应用市场”那种巨大的业务灵活优势,肯定会有下半程。我们花这么大劲,要从历史背景和技术趋势开始推演分析,就是想看看下半程可能会是怎样的落地形态,不是么。

云网融合这个方向必然是对的,符合“先理解-后优化”的工程规律,甚至也早已大规模成熟商用,而且你我每天都在重度使用。

再回到移动通信网,其中诸如3G接入网中的RNC全称是什么?Radio Network Controller,无线网络控制器啊(4G/5G也有类似网元,选3G是因为网元名字最形象),早已在大规模使用SDN思想了。为什么无线接入网要采用SDN架构?因为只有SDN的“中央集权式”架构,才能让网络资源的调配速度,可以跟上无线信道的快速变化,保障终端用户业务的连续性,又回到了“身在网络,心怀业务”的初衷,这种改动,算不算“云网融合”呢?

所以,作者觉得云网融合还有一个更为广义的理解,应该是:“你们不要绕来绕去扯了,我不懂也没时间听,你们就说能不能解决我的问题”。

好像历来只听到乙方在谈“云网融合”,很少听到甲方会主动谈起“云网融合”,为什么?我想甲方只关心问题的答案,只不过有些问题,当前还没最优解,乙方不得不抱起“云网融合”的概念,一边向用户求谅解,一边向内部指方向,一边向伙伴寻合作。所以,说到底,作者觉得掰扯概念不重要,甚至技术也不重要,能结合自身的产品体系,落地原理,服务生产才重要。

一些必要的注解:

  • 说Google做云业务并不成功是相对AWS和Azure而言的;特别提到Google是因为,动互联网大厦根基这种事,觉得技术难度是其次的,推动行业去认可去落地的难度是天量的。敬佩这类有追求有“技术责任感”的公司。
  • 说RNC是SDN,可能会有严谨的学术派反对,因为3G RAN侧确实没有在大规模使用通用硬件。因为作者认为“能结合自身的产品体系,落地原理,服务生产才重要”,所以没有这个困扰。

为什么要云网融合

既然这里谈的“云网融合”和巨头大佬谈的概念不太一样,那么“为什么要云网融合”的视角,可能也就不太一样了。

所有的“为什么”,最终都会归于“需求”这个本源。在上一篇中,引出了网络云化领域“房间里的大象”——5G。这头大象,同样是云网融合领域中的翘楚。

因为以下分析的基础是承认5G的需求;发现当前对5G诸如1ms这类场景的意义,还有不少质疑,认为4G和固网,已完全够用,5G是个噱头。所以先来快速解释一下为什么直接承认5G的需求:

首先,这是ITU的专家们经过广泛的调研论证得出的,他们是当前这个领域最资深的人。可以挑战权威,不过在挑战之前,建议先了解背景。不过这是通信强相关的小众领域,稍后可以专门介绍一下ITU、3GPP、ETSI之类组织的背景和关系。

其次,所有人在新技术面前,都是容易短视的,甚至包括这些专家们。其实可以从他们为4G命名可以看出来,什么IMT-Advanced,什么eNB (Evolved Node B),你都“Advanced”了,你都“Evolved”了,那5G该叫什么了?这下傻眼了吧,哇哈哈,图片。

最后,这是关乎国家安全和利益分配的社会根基领域,必须要看国家意志。看到过一个比较有意思的问题:“日本近年来为什么总是点错科技树”?可能部分有日本故意就是要保持一定独立性的“安全感”的需要,不过更有说服力的原因是:“大国永远是带着日本玩,而不会跟着日本玩”,残酷而现实。5G已经成为一个直接较量的领域,已经形成“Lead Follow or Get Out of the Way”的态势了。质疑者总是容易正确,不过还是建议去做时间的朋友。:-)

以下就从MEC、IoT、SASE三方面的视角,分析一下为什么要云网融合。

边缘计算 MEC

5G的三大应用场景,无论是ms级时延,还是Gbps级的速率,都决定了5G业务的终结点,不可能继续留在核心网后端的云平台,而需要向数据源或消费地靠近。这里说的是“业务终结点”,而不是“任何网络协议的终结点”,所以就不再是传统意义上的网络,而是依托网络的应用,即“云网融合”,这也正是MEC的根本契合点。如果需要这方面最直观的例子,可以参考《最深的云网融合:多接入边缘计算(MEC)》。

物联网 IoT

5G在设计之初,定位的通信主体就是物。万物互联,一方面意味着海量数据的产生,另一方面意味着海量的物联网设备,这些海量的物联网设备,大多是缺乏“思考”能力的,需要近场网络帮它们实现物物之间的传感、交互和控制。这里说的“传感、交互和控制”,也都不再是传统意义上的网络,而是依托现代网络的应用,即“云网融合”。所以,从这个意义上讲,最好别把物联网当作网络来理解,理解成应用反而会更合适一些;只不过这类产业互联网下的应用,需要设计者理解更多的网络原理。

SASE

SASE号称是面向边缘计算和物联网的SD-WAN演进,那自然也是离不开“云网融合”的。SASE没有5G的标准协议可以精确查看,但基于它的出身背景,不妨碍对它进行相关推演。在面对边缘计算和物联网场景,SASE不再假定固定边界,而是基于身份和其他相关策略,形成动态的信任边界。

这意味着:工作在传统边界的设备,诸如网络领域的广域网加速设备,诸如安全领域的防火墙设备,如果还是继续游离在网络之外而没法融入其中的话,就会统统失效。所以,基于一个云化网络的,可以快速向目标区域投放动态边界所需的网络能力和安全能力,是可以充分发挥SASE竞争力的关键。

如此,产业互联网下的产品趋势,慢慢都是相通的了,云网融合成为了一个必需。

所以,不要把边缘计算理解成计算,不要把物联网理解成网络,当然,更不要把5G理解成网络。

怎么实现云网融合

慢慢从“道”偏向“术”,所以会相对枯燥;不过这里不会涉及很多细节,即使选图也是选择足够示意的简化版本。对哪部分感兴趣,可以查阅对应文档。

具体怎么实现,如果认同5G是云网融合的翘楚,那么看看5G的演进就能知道个大概。

SDN/SD-WAN

三个层次:

  • 基础设施层:专注于数据转发。可以是硬件设备:从芯片级到设备级,基本上各个大厂都有。芯片级的有OpenFlow芯片,以及更加灵活的P4芯片;设备级,基本上所有传统大厂都有。也可以是软件形态:比如开源的OVS。
  • 控制层:整个基础设施层的控制中枢。可以大致分为两类:买设备“送”的,也就是各大设备厂商的控制器;期望自己主导的开源方案,比如OpenDaylight,以及后起之秀ONOS。
  • 应用层:直接对接业务需求,然后编排成各种网络需求,再由控制器编排出对各个基础设施的控制指令。

两种接口:

  • 南向接口:控制层到基础设施层的接口。上图来自ONF,所以只画了OpenFlow,但是南向接口不止OpenFlow,包括相对传统的NetConf等,都是可以使用的接口。南向是个容易有争议的接口,Openflow之类协议,支持和顾虑的人,应该都是排着队的,所以还是赶紧闪开。
  • 北向接口:应用层到控制层的接口。大多会采用RESTful API形式,也有大型设备商演进过来的编程接口。

NFV

三个层次:

  • 基础设施层(NFVI, Network Functions Virtualization Infrastructure)。将各种物理资源抽象成计算/存储/网络资源池。有意思的是,因为这个资源池是暴露给软件的逻辑资源池,所以资源池可以有多大,还会取决于其下的网络能力,SDN技术就是很好的契合点。
  • 虚拟网络层(VNF, Virtual Network Functions)。在虚拟的计算/存储/网络资源池,将原先的物理网元映射为一个虚拟网元,所以叫VNF。
  • 运营支撑层(OSS/BSS, Operations/Business Support Systems)。OSS,运营支撑,BSS,业务支撑;它们直接对接内部的运营需求,以及外部的业务需求。

接口部分相比SDN要复杂,而且因为是由ETSI在规范,所以话风都变了,称为参考点(reference point)。ETSI NFV框架在稍后分析5G以及MEC时,会重点涉及,暂不展开。

大融合

ETSI的NFV框架如何运作?OSS/BSS对接了客户和运维,MANO(Management and Orchestration)对接了OSS/BSS;MANO会将一个业务需求,自顶向下分解编排,直到可分配VNF资源为止;然后对应的VM等资源,由NFVI来分配,对应的VNFL资源(可以认为VNFL是连接资源,暂不展开介绍,后续梳理MEC时会重点展开),需要与承载网的网管系统交互,由承载网来分配。

以上,“与承载网网管系统交互,由承载网来分配”说的是可以与SDN系统集成。事实上,ETSI已经在融合NFV和SDN了。

以上,如果参照OSI参考模型,SDN/SD-WAN主要在软件定义2-3层,比如交换机、路由器等;NFV主要在软件定义4-7层,比如防火墙,负载均衡等。

如此,整个协议栈都可以软件定义了,再加上两者都推崇的硬件解耦,就在物理上和逻辑上,都达到了“敏捷”、“弹性”、“按量付费”的技术特点,就又回到了“网络云化”、“云网融合”了。如果你把OSI理解成了网络,那就是“网络云化”;如果你认为OSI包含了应用,那么就也做到“云网融合”了。

之前提到5G是云网融合方面的好手,那我们最后就反过来看一下5G的大致的演进逻辑:

核心网NFV化

  • 核心网元虚拟化,硬件解耦。
  • 核心网元模块化,并采用SBA架构,逻辑解耦。

接入网NFV化

分离成AAU、DU、CU;CU进一步NFV化。如此,完成“力所能及”的硬件解耦和逻辑解耦。说“力所能及”是因为还有OpenRAN的存在,暂不展开。

承载网SDN化

变态的需求导致了变态的架构,变态的架构导致了变态的部署模式,变态的部署模式进一步导致了大量的3层动态组网需求,进一步导致了SD-WAN演进。

太啰嗦了,有没有更直接的例子?有啊,以上不就是大名鼎鼎的“切片”了么。:-)

后记

预测趋势要比预测时间点简单得多,一些分析判断:

5G、物联网、边缘计算等技术革新,不是为了技术而技术,而是为了能将数字化、信息化、智能化,从消费互联网行业,延展到更为广阔的产业互联网领域。尤其是5G,它不再只是通信那么简单了,更是为了延续产业革命而生。最直接的作证:为什么一个国家可以突破想象力的下限,不要脸到直接下场去干涉一家5G领军企业?没被逼急时,人都是要脸的,更何况是长期以灯塔自居的美国——因为太重要了。

为什么产业互联网重要?因为第三次科技革命所能支撑起的消费互联网,已经接近尾声了,存量搏杀越来越激烈,政府、企业,都迫切需要新的增量来安抚“不安的灵魂”。除了入网人数增长乏力外,一些其他可以看出“尾声趋势”的迹象:

  • 创新的层次越来越高,很多都已经不得不滑入到业务模式创新了,譬如被官媒点名的“社区团购”。这生意合法吗?完全合法。那为什么巨头要被点名?因为你们号称是“科技巨头”啊,这种“创新”,还没开始就可以预见结局了——大资本支持下的小贩挤压和行业垄断,客气点说,已经很难判断社会价值和社会问题,哪个会更大一些。
  • 争抢的越来越激烈。消费互联网越接近尾声,在争抢的就越成了“国民总时间”。抖音产品大成了,用户停留时间长了,那么微信朋友圈的停留时间就不可避免地减少了,瞎猜这也是微信推出了短视频的原因之一吧。

那当下产业互联网为什么难做?除了技术原因之外,需要的主流创新模式不同。越上层的创新,复制起来也相对越快,这也客观造就了当下能直接复制解决的问题,大部分都已经解决了。那为什么从消费领域往产业领域渗透时,就复制不过去了?

因为跟消费互联网是个大池子不同,各个产业领域当下还是待开发地块,有着大量的现实的“坑”需要躬身去“踩”;这些不是快钱,习惯上层创新赚2C快钱的互联网公司,不一定能忍受这种孤寂和苦哈哈,反倒是传统行业的从业者,相对更有这种品质。

这种情况下,需要ICT(Information and Communication Technology,信息和通信技术)领域与各个行业领域,能有更加广泛而深入的交流与融合,在原理层面相互理解贯通,才有可能孵化出更有意义的产品。

本文图片均源自网络,如有侵权,可联系删除


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

登录后才可以评论

SDNLAB君 发表于21-04-14
0