英语Costomer-premises equipment怎么翻译?

关于“SD-WAN能否取代传统的MPLS VPN”,其实这个问题的答案很明显。SD-WAN最大的价值之一,就是在Hybrid WAN的场景下更有效地去管理与使用WAN线路,帮助企业提高在WAN这一块的ROI。因此,SD-WAN的出发点并不是要对抗MPLS VPN,因此就谈不上要取代MPLS VPN,因为两者并不在一个层面上。

无论是从纸面上来看设计,还是从实践中看效果,SD-WAN确实实现了它所承诺的价值。运营商也很快地就看清楚了问题的本质,尽管SD-WAN客观上会降低企业对于MPLS VPN的需求,但这是技术演进的自然结果,另外SD-WAN在灵活性、自动化、应用感知、上云等方面相比于传统的技术方案,也有着不可比拟的优势。权衡之下,与其把SD-WAN放到对立面,倒不如想办法把其拉到统一的战线上,作为一个新的业务增长点。因此,运营商并没有排斥SD-WAN,而是对其表现出了相当开放的态度,这与很多人的设想是恰恰相反的。

SD-WAN的厂家们心里也很清楚,要做大事情就一定得把生态搞好,运营商作为生态中最关键的环节,有必要建立起一个融洽的合作模式。首先,纯Overlay的方案存在着一定的局限性,虽然说是Transport Independent,但是如果Transport的线路质量确实不行,那也是巧妇难为无米之炊,另外对于跨国企业来说,如果不用MPLS纯走Internet,那么基本上就约等于不能用。其次,运营商拥有着广泛的客户基础,业务的覆盖范围更广,无论在运营还是运维方面都有着巨大的优势,这正是SD-WAN厂家们最为欠缺的环节,一些大型的客户动辄就几千个分支,虽然技术上是ZTP + Cloud Managed,但是从渠道和服务的角度来说,就完全是另外一回事了。

双方一拍即合。第一种合作的思路是,运营商把厂家的方案买下来,然后自己来做渠道和服务,除了能够分一部分SD-WAN的利润外,更关键地是可以把各种WAN线路打包到方案中,为企业提供一站式、差异化的WAN解决方案。如果有足够实力的话,还可以对产品进行一些定制,把SD-WAN的能力嵌入到自己的业务系统当中。第一种思路,不需要对Enterprise Oriented SD-WAN的技术架构进行改动,同时有着清晰的盈利模式,对于厂家来说是零成本,对于运营商来说是一种快速进入市场的有效手段。

第二种思路,是对原有方案的架构进行调整。最初所设计的SD-WAN方案是Enterprise Oriented的,从技术上来看是找不到运营商位置的,如果要做一个SP Oriented的SD-WAN,就需要在方案中引入SP的角色。那么SP Oriented SD-WAN该怎么做呢?

厂家给出的方案,是在运营商的POP点里面放SD-WAN Gateway,负责终结企业侧CPE发起的隧道,然后转发到运营商的IP/MPLS网络。在这种方案中,Enterprise SD-WAN中的CPE上所有能力都被保留了,不过端到端的Overlay变成了,两头的Last Mile用Overlay而Middle Mile交给运营商去做,如果运营商有能力的话就可以把MPLS

实际上这是种很不错的思路,各方接受起来都很自然。从客户的角度来看,不需要去额外地购买的设备,而且传统的WAN设备也可以通过隧道接进去了,另外SD-WAN的运维也转交给运营商去做了。从厂家的角度来看,Enterprise Oriented的特色得以被保留,CPE仍然是高价值的产品,同时有效地解决了纯Overlay的局限性,另外通过SD-WAN Gateway也得以参与到运营商的组网中。从运营商的角度来看,SD-WAN Gateway不仅提供了对接MPLS的入口,另外也提供了更加灵活的接入方式,对于Last Mile不可达的Off-Net Customer,走Overlay做接入能够省去很多的麻烦事儿。

对于运营商来说,SD-WAN Gateway作为业务的接入设备,在位置上和SR/PE并没有本质上的区别。对于Pure Play的SD-WAN厂家来说,他们在POP里面并没有存量的SR/PE,所以就只能推新的设备进去。形态上就是x86的盒子,相比于Enterprise Oriented SD-WAN方案中的CPE,SD-WAN Gateway作为不同客户流量的汇聚点,接口的速率和数量都会做相应的增强,而且由于它要负责大量隧道的终结,因此对CPU和内存的要求高很多,通常会需要专用的Crypto Accelerator。而对于传统的设备厂商来说,比如Juniper、ALU和华为,他们在POP里面有存量的SR/PE,这时候可以选择把SD-WAN Gateway以板卡的形式插到SR/PE的机框上,以避免多引入一个物理设备的麻烦。随着CORD在运营商中的推进,SD-WAN Gateway的形态开始逐渐向vCPE进行靠拢,关于vCPE等到后面CORD的部分再来做介绍。

控制器。从宏观的架构来看,除了Staging Server、Controller和Analytics以外,可能会需要AAA来专门做鉴权。从细节来看,由于多租户需求的出现,以及设备、拓扑复杂度的提高,使得控制器所用的数据模型以及业务流程都会发生一定的变化。从位置来看,On-Premise是不可行的,需要放到运营商自己的机房当中。通常是在地市级的核心机房里面,负责控制下属的各个接入机房中的SD-WAN Gateway,以及本地企业分支的CPE。

Portal也要做相应的调整,而且运营商很可能要自己来做定制,部署的位置也取决于运营商站在什么层面上来看待SD-WAN的业务,所以这里就不多说了。

1.2 多租户是怎么实现的?
Gateway的流量,需要能够与VRF进行关联。按厂家的意思就是用IPSec直接打进来,把接入网这一段OTT掉。在这种方式中,需要能够对IPSec流量关联VRF,大概有下面这几种办法:(1)用GREoverIPSec,为GRE口关联VRF;(2)用MPLSoverGREoverIPSec,用MPLS来关联;(3)用VxLANoverIPSec,通过VNI来关联VRF;(4)通过VTI口来关联VRF;(5)用ISAKMP Profile绑定VRF,识别SPI后直接关联VRF;(6)用私有的IPSec封装,在IPSec后面单独加VPN的字段。比较而言,从标准化程度来讲(1)是最好的,从封装效率上来讲(3)和(4)要好一些,不同厂家的实现中会有不同的选择。

不过,按运营商现有的接入网络来看,除IPSec以外,VLAN/QinQ/L2TP/GRE/MPLS VPN甚至是传输专线都有是有可能的,这对于SD-WAN Gateway的要求就比较高了。此时,传统的设备厂商相比于Pure Play的厂商就有明显的优势了

经过特定VRF的路由后,这里考虑跨地区的流量,流量要被送到目的站点所接入的SD-WAN Gateway上。根据实际情况,又有不同的方式:(1)如果SD-WAN Gateway间要走GRE/IPSec,就还是用上面刚刚所介绍的方法;(2)如果SD-WAN Gateway间要走MPLS VPN,且SD-WAN Gateway自己具备MPLS VPN的工作,这实际上可以看作是VRF-Lite的方案。

不仅是SD-WAN Gateway,整个系统实际上都需要进行多租户的改造。对于CPE来说,要接入SD-WAN Gateway,可能需要对特定的封装提供支持。对于控制器来说,要明确CPE所属的租户,以及SD-WAN Gateway上所接入的租户列表,然后在分发策略和路由的时候,需要能带着租户的信息下去。对于Portal来说,则要提供RBAC的能力,对不同账号的权限进行区分与隔离。多租户所带来的细节问题,还有很多很多,无法逐一而述了。

1.3 端到端的控制如何实现?
在Enterprise Oriented的方案中,控制器看待站点间的连接的角度很简单,两个设备+双向的隧道。在SP Oriented的方案中,由于控制器不仅要控制企业侧的CPE,还要控制运营商的SD-WAN Gateway,另外SD-WAN Gateway的引入还将路径切分成了多段,路由的控制上也很为复杂了。这些都对SP Oriented的控制器提出了很大的挑战,甚至可能需要在集中式和分布式间重新进行决策。

SD-WAN的设备打隧道接进来,这个设备的控制是不归控制器来管的,虽然控制的设备少了,但实际上控制器的建模却变得更加复杂了。如果Non SD-WAN设备接入SD-WAN Gateway,而SD-WAN CPE间不走SD-WAN Gateway直接打隧道,就更加混乱了。和路由目前来看,SP Oriented SD-WAN还没有一个标准的路由控制逻辑,只能是摸着石头过河。

在实际的部署中,SD-WAN Gateway不可能会是单点,相比于主备运营商更喜欢负载分担,那么还要考虑HA下的均衡问题。而且一个地区的POP点会有很多个,如何在POP点间进行流量的优化,也是一个重要的问题。

另外一个现实的问题是,运营商不可能完全OTT接入网和MPLS。Overlay在Internet上做接入,虽然在灵活性上有很大的优势,便于接入Off-Net的客户,但是对于本地的On-Net客户这种方式却不见得合适。对于一些运营商来说,CPE—BRAS—SD-WAN Gateway—SR/PE的流量模型并不符合路由的规范,而且BRAS、SD-WAN Gateway、SR/PE这三者间的形态关系也是千差万别,现网部署起来会遇到很多麻烦。所以说对于On-Net的客户,SD-WAN Gateway接入这一端更习惯于over在专线上。这样的话还要协同接入网的网管/控制器,如果再考虑与MPLS VPN网管/控制器的协同,整个SP Oriented SD-WAN的编排/控制系统会变得无比复杂。全场景、端到端的编排/控制,目前来看还有相当大的差距。

Gateway能够提供NAT、安全和HQoS的相关能力,同时要求SD-WAN Gateway具有Internet的连通性。对于客户来说,Regional Break Out的优势在于,既可以避免Internet流量绕行总部/数据中心,降低了时延与带宽消耗,又可以通过SD-WAN Gateway为本地的多个分支集中地提供安全、WAAS这些服务,避免了以分支为单位去使用这些服务的成本。对于运营商来说,客户在本地所有分支的Internet业务可以集中地管理起来,比如对上下行带宽的统一分配。

Gateway—Internet,在现网中运营商不一定会愿意提供这种连接方式,这取决于运营商如何去看待BRAS和SD-WAN Gateway两者的关系。如果是over在专线上,路径上就不会出现BRAS,这时相当于一根线上同时跑了宽带和VPN两种业务,需要在计费方式上做好考虑。

在运营商传统的POP点中,为了支撑话音、宽带、专线等不同专业的业务,需要采购大量专用的硬件设备,开放性和灵活性很差。在Cloud/NFV/SDN等新型架构的驱动下,全球各大运营商纷纷投身于POP点云化的重构进程中。POP点云化后,各类专用的硬件设备在形态上将被基于通用x86平台的VNF所替代,在架构上转发和控制得以分离解耦,这对于运营商具有巨大的价值。一方面在于开放性、灵活性等方面的提高,长期来看能够有效地降低成本。另一方面,运营商得以将各种增值服务的VNF以服务的形式提供给客户,这将是一笔相当可观的业务增收,也是破局“管道化”困境的有效方式。

在这一大背景下,SD-WAN的架构也得到了新的延伸,以vCPE为核心的解决方案开始占据SP Oriented SD-WAN的主流。这里有必要对vCPE的概念进行一下说明,从字面上来直观理解的话,vCPE应该是指一个与CPE具有相同功能的VNF,但实际上业界对于vCPE的定义并非如此。由于传统的CPE是一个泛指的概念,涉及路由、防火墙、WAAS等诸多技术,因此对CPE进行虚拟化的结果,通常并不是一个VNF,而是vRouter、vFW、vWAAS等多个VNF,它们各自完成一部分功能,然后通过服务链串接在一起,共同交付vCPE的能力。虽然在某些产品和语境下,vCPE可以指代一个特定的VNF,但是在通用语境下vCPE是指一套完整的解决方案。

  • 如果SD-WAN CPE是基于x86的白盒,而且自身具备单独作为vCPE载体的能力,这时SD-WAN CPE就可以被称为vCPE,vCPE就是SD-WAN方案中的一个组件。
  • 如果SD-WAN CPE以虚拟机的形态存在,那么可以作为vCPE方案中的一类VNF,这时可以说vCPE是SD-WAN方案中的一种实现手段。

如果理解起来仍然比较晦涩,那么换作vCPE的角度来看就清楚很多:

  • 如果所有的能力都在企业边缘提供,称为Distributed vCPE,无论企业边缘的设备是不是SD WAN CPE。
  • 如果一部分能力在企业边缘提供,一部分能力在POP点提供,称为Hybrid vCPE,无论是否存在SD WAN CPE或者SD-WAN VNF。

可以看到的是,SD-WAN和vCPE并不存在严格的包含于被包含的关系。以这篇文章的出发点来说,可暂且把vCPE看作是SP-Oriented SD-WAN中的一种实现形式。下面就来对vCPE进行一个简单的介绍。

vCPE中的x86资源池中。其次,要有一套虚拟化的中间件+云管平台,如开源的KVM+OpenStack。然后,需要一套VNFM+NFVO,对VNF进行管理和编排。SDN这块,云POP点的控制器、SD-WAN的控制器,可能是同一套,也可能是两套,另外一些方案中还会包括接入网的网管/控制器。Portal就很难说了,完全取决于厂家的实现和运营商的集成。

vCPE是否要做成多租户的?除了厂家的实现以外,其实还取决于运营商的销售策略。如果是卖VNF的模式,那么一个实例只就能属于一个租户,这时不强制要求多租户。如果并不直接卖VNF,而是包装成网络能力来卖,这时做成多租户就比较划算了,不过要考虑好性能、容量、配额和扩缩容的问题。

实际上,vCPE就是POP点云化的一个企业级用例,上述vCPE的架构也就是POP点云化的架构。关于这套大的架构,本身就可以独立成一篇长文,这里不做深入的展开。

vCPE,所有能力都位于POP点中,并由运营商以服务的形式来集中提供。那么,哪种方式更好一些呢?

先来看看市场方面的因素。从厂商的角度来看,如果其产品的能力比较全,就会倾向于Distributed的方式,把所有的功能都自己做在盒子里,如果其产品能力上有较大的缺口,那不可避免地就要做第三方集成,倾向性就会稍弱一些。从运营商的角度来看,一般会更倾向于Centralized的方式,一方面有利于运维,另一方面能够增强自身在企业组网中的地位。从客户的视角来看,Distributed是买硬件+服务,Centralized只需要买服务,如果Distributed和Centralized的使用体验一致,从成本来说自然是Centralized更好一些

不过,Centralized并不会完全地压倒Distributed。一来,目前运营商的POP点云化还处在早期的阶段,技术上距离成熟还有相当的一段距离。再者,一些VNF部署在企业边缘会获得更好的使用体验,比如WAAS。Hybrid vCPE在两者间取了一个平衡,一部分能力在企业边缘的盒子上,一部分能力在POP点中,由客户根据实际情况来自行订购。Hybrid的方式固然灵活,但是VNF的分散性对于运维来说是一个不小的挑战。

vCPE的目标是最大程度地简化企业侧的设备,最好是只留下二层的功能,把路由也移到POP点里面去。对于运营商来说,自然希望借此获得对于企业业务更加完整的控制权,对于一些中小型的客户来说,这避免了自己去维护路由的工作,实现网络的即插即用。因此,目前在很多的vCPE应用案例中,都会见到这种二层接入的方式。这时VPN和公网的流量都会发给POP点中的vCPE,vCPE不仅仅是虚拟化了企业侧的终端,实际上把BRAS和SR的一部分活儿也都一起给做了。

Centralized vCPE主要包括vRouter、vFW和vWAAS,在实际的部署中会有不同的串接顺序。当然,某些厂商也会将不同的能力集成到一个VNF中去实现,比如SD-WAN VNF很可能就是一个集多种能力于一身,这时流量的模型就要简单很多。这里考虑最常见的串接顺序vRouter—vFW下的流量模型,vFW采用路由模式。vRouter对流量的处理主要包括:(1)对流量进行识别;(2)为企业侧的接入设备分配IP地址;(3)对流量进行限速;(4)将流量送给vFW。在vFW对流量的处理主要包括:(1)对流量进行识别;(2)对公网流量和VPN流量进行分流;(3)执行安全策略;(4)公网流量送给NAT设备,VPN流量送给PE。

具体来看数据面的转发。目前NSH的应用还非常少见,这里不做分析。

    GW—vSwitch—vRouter)。由于要接入二层,因此可以选择VLAN/QinQ或者VxLAN,考虑到与物理拓扑解耦走VxLAN会稍好一些,一些节点上会需要做转换/拼接。

可以看到的是,由于涉及到运营商的网络,因此底层的连接变得非常复杂,要针对现网的实际环境来做具体的方案设计。而且,由于拓扑没有一定固定的形态,因此对控制器的要求也很高,很可能需要做一些定制化的开发。

从SD-WAN厂家的角度来看,只要把流量做好标记送给PE上就行了,PE间的打通并不属于SD-WAN要考虑的问题。不过对于运营商来说,MPLS VPN是企业广域网业务的基础,也是能够体现服务差异化的最关键环节。因此,运营商在设计SD-WAN业务的时候,一定会带上MPLS VPN一起做考虑。不过,传统的MPLS VPN所存在的一些局限性,使得它在与SD-WAN进行集成时显得很不协调。首先,开通周期太长,交付速度远远跟不上业务的需求。其次,带宽难以按需调整,客户只能按照峰值带宽的水平进行超买。另外,无法与云进行联动,企业入云的流量难以纳入到服务体系中。

快速开通的问题,并非单纯地引入SDN控制器对两端PE/ASBR做自动化配置那么简单。在运营商的传统体系下开通一个MPLS VPN,周期保守估计在45-90天,从开始填写订单到最后完成交付,其间要流转数十个步骤,其中向设备下发配置这个环节已经是由MPLS VPN网管一类的角色自动完成的,换上SDN控制器来配也没有任何本质的区别。真正的问题在于,传统的BOSS系统太过于臃肿,为保证系统的稳定运转,不仅流程复杂繁琐,而且很多步骤需要人工介入。因此破题的关键在于,运营商要对BOSS的架构和业务流程进行精简,否则任何网络层面的改进都是杯水车薪。

带宽按需调整,在BOSS层面也面临着同样的现实问题。单纯从网络的层面来讲,调带宽的方法要看MPLS VPN的QoS模型,如果是Diff-Serv的就是在PE上做限速和Mark,如果是Int-Serv恐怕就要去搞RSVP了。想法是好的,但在现实中运营商可能会遇到一些头疼的问题。首先,是调带宽这个动作极容易使网络变得不稳定,一旦客户调的时候影响了别人,很难去界定责任。其次,按需的粒度很难掌握,细了的话太影响收入,粗了很多时候对客户就失去吸引力了。另外,按需服务的模式对计费系统冲击太大,风险性需要进行谨慎的评估。

与云的联动不足,需要运营商与云提供商双方来共同解决。云机房通常会建设在城域网核心或者骨干网这一层面,通过DC Edge来接入运营商的Internet。随着云计算的逐步成熟,一些高价值的企业流量开始流向云端,然而Internet却难以为这部分流量提供足够的连接质量,引入MPLS VPN来解决这一问题是很自然的需求。对于运营商而言,如果不是市场策略上有什么额外的考虑,单纯从技术上来讲事情是很简单的,DC Edge就是CE,只要搞定它与PE间的接入和路由就可以了。

接入上没什么说的,裸纤/专线/VPN都可以,对于几个大的公有云,甚至可以直接把PE搬到DC Edge的机房去做直连,通过物理接口或者子接口来隔离租户。如果由于一些现实的因素,运营商和公有云间做接入存在困难,还可以通过第三方的IXP/CXP来进行中继。

路由这一块,由于要跨域一般就是静态路由或者BGP,如果是用静态路由,就是由控制器把路由配到DC Edge和PE上,如果是用BGP,那就需要控制器去配好Peering和Policy。从分工界面来看,DC Edge和云内部的网络由公有云提供商来负责,PE和企业侧的接入由运营商来负责,双方的控制器各自封装好API提供出来,上面的Portal或者编排器拆单后直接调用就可以了。对于IaaS流量来说,企业侧和云侧的网络在同一地址空间内,路由直接拉通就行了,但是对于SaaS流量来说,云一侧是公网的IP地址,因此路由是没法直接通的。因此,对于企业侧访问SaaS的流量,运营商还需要在PE送到DC Edge前做NAT,这是一个很容易被忽略的问题,特此进行提示。

边缘计算作为颇富新颖的前沿思想话题之一,已经在当今技术时代思潮中占据了一席之地。几年来,人们一直认为这种计算方式是未来的发展方向。直到现在,这种论调仍停留在理论阶段,因为能够支撑边缘计算的基础设施尚未出现。

随着各种边缘计算资源(从微数据中心到专业化处理器,再到必要的软件抽象)逐渐涌入应用程序开发人员、企业家和大型企业的手中,这种情况正在发生变化。在回答有关边缘计算的作用和影响的问题时,我们现在可以试着超越理论层面。那么,关于这一趋势,现实世界的案例能给我们什么启示?特别是,围绕边缘计算的炒作究竟是实至名归,还是不合时宜?

总的来说,事实表明边缘计算趋势真实存在,它是由于成本和性能原因而产生的一种新兴的去中心化应用程序的需求。边缘计算的某些方面正在被过度炒作,而另一些方面则没有引起应有的注意。以下四个要点旨在帮助决策者对边缘计算现在和未来的能力有一个务实态度。

边缘计算是一种使计算和数据存储得以有的放矢的范例,它与将计算集中在少数几个超大规模的数据中心的传统云计算模型形成鲜明对比。“边缘”可以是指任何比传统云数据中心更接近终端用户或设备的地方,它可能在100英里外、1英里外,甚至是就在现场或设备上。无论采用哪种方法,一般对边缘计算的描述都强调,边缘计算的强大功能是延迟最小化,从而改善用户体验或为启用新的对延迟很敏感的应用程序赋能。但这样的说法的确对人们全面认识边缘计算很不利。虽然对边缘计算来说,缓解延迟是一个重要的应用案例,但它却可能不是最有价值的。边缘计算的另一个应用案例是最小化进出云的网络流量,也就是一些人所说的“云卸载”,这可能会带来至少与缓解延迟一样多的经济价值。

云卸载的潜在驱动力是生成数据量的突飞猛进,无论是在用户、设备还是传感器层面。Macromet公司首席执行官Chetan Venkatesh去年年底曾向作者表示,“从根本上讲,边缘计算是一个数据问题”,云卸载之所以出现,是因为移动数据需要花钱,而且如果没有必要,许多人宁愿不移动它们。边缘计算提供了一种从本地设备直接提取值的方法,因为它不会将数据移到“边缘”之外。如果有必要,可以将数据精简为一个更为经济的子集,并发送到云端进行存储或进一步分析。

云卸载的一个非常典型的用途是处理视频或音频数据——这是两种最需要带宽的数据类型。据我最近接触到的一位参与部署的人士透露,一家在亚洲拥有1万多家分店的零售商正在运用边缘计算技术同时处理这两项业务,以进行视频监控和店内语言翻译服务。但除此之外,还有其他的数据源也需要花费同样多的钱才能传输到云中。另一位知情人士透露,为了防患于未然并优化性能,一家大型IT软件供应商正在分析来自其客户的内部IT基础设施的实时数据,并使用边缘计算来避免将所有这些数据返回到AWS。同时,工业设备也会产生大量的数据,是云卸载技术的主要应用场景。

尽管在初期有关于边缘计算将取代云计算的说法,但毋宁说是边缘计算拓展了云计算的范围。边缘计算虽然不会对工作负载迁移到云的趋势造成影响,但是,一系列活动正在为了将按需资源可用性和物理基础设施抽象的云计算公式扩展到距离传统云数据中心越来越远的位置而进行。这些边缘位置将使用来自云端的工具和方法进行管理,随着时间的推移,云和边缘之间的界限将变得越来越模糊。

边缘计算和云计算是同一连续体的一部分,这一事实在AWS和Microsoft Azure等公共云提供商的边缘计算解决方案中得到了证明。如果你是一家想要部署本地边缘计算的企业,亚马逊将会为你提供一项叫做AWS Outpost的服务——一个模仿了亚马逊自己数据中心的硬件设计的完全组装好的计算机和存储机架。它将被安装在客户自己的数据中心,并由亚马逊进行监控、维护和升级。重要的是,AWS Outpost运行着AWS用户所依赖的许多相同的服务,这使得边缘计算在操作上类似于云计算,例如EC2计算服务。微软的Azure Stack Edge产品也有类似的目标。这些产品都发出了一个明确的信号——云提供商希望将云计算和边缘基础设施统一在同一个“保护伞”下。

虽然有些应用程序最好在本地运行,但在许多情况下,应用程序所有者希望获得边缘计算的好处,而不必支持任何本地占用。这就需要访问一种新的基础设施,这种基础设施看起来很像云,但在地理分布上要比现在组成云的几十个高级别数据中心分散得多。这种基础设施现在才刚刚开始使用,它可能会分三个阶段发展,每个阶段都会通过越来越广泛的地理足迹扩大边缘计算的覆盖范围。

关于边缘计算的第一步,很多人没有考虑到的是将其应用到大量应用程序当中,但这可以视为所有边缘计算处理的频谱终结。这一步就是利用公共云提供商所提供的多个区域。例如,AWS在22个地理区域拥有数据中心(另有4个已发布),其中,为北美和欧洲用户提供服务的AWS客户就可以在北加州地区和法兰克福地区也运行其应用程序。对于一组大型应用程序来说,从一个区域到多个区域可以大大减少延迟,这将是其提供良好用户体验所需的全部。

与此同时,在一系列考虑因素(包括成本效率、风险降低、避免厂商锁定以及希望访问不同提供商提供的最佳服务)的驱动下,出现了向多云方法发展的趋势。分布式云初创公司Volterra的首席营销官Mark Weiner告诉我:“在今天,做多云并把它做好是一个非常重要的战略和架构。”与多区域方法一样,多云方法标志着云计算朝着分布式工作负载迈出了第一步,而分布式工作负载正朝着越来越分散的边缘计算方法发展。

边缘计算发展的第二阶段将扩展到更深一层:利用数百或数千个地点的基础设施,而不是几十个城市规模大小的超大数据中心。事实证明,已经有一群玩家拥有了这样的基础设施部署,即内容分发网络。20年来,内容分发网络一直是参与边缘计算发展的先驱,为了提高性能,其将静态内容缓存到更接近终端用户的地方。目前AWS有22个区域部署了这样的基础设施,而像Cloudflare公司这样的典型提供内容分发网络服务的则有194个区域。

现在不同的是,这些内容分发网络已经开始向通用工作负载开放其基础架构,而不仅仅是静态内容缓存。如今,像Cloudflare、Fastly、Limelight、StackPath和Zenlayer这样的内容分发网络提供商纷纷开始提供一些容器即服务、虚拟化应用即服务、裸机即服务和无服务器功能的组合。换句话说,他们开始变得更像云提供商。像Packet和Ridge这样具有前瞻性的云提供商也在提供这种基础设施,而AWS也朝着提供更区域化的基础设施迈出了第一步,在洛杉矶引入了第一个它称之为“区域型”的的新公有云服务,并承诺将在更多区域予以部署。

在向前发展的第三个阶段,边缘计算将进一步向外驱动,直到距离终端用户或设备只有一两个网络跳数。在传统的电信术语中,这被称为网络的接入部分,因此这种类型的架构被标记为接入边缘。接入边缘的典型组成因素是微型数据中心,其大小可以从单个机架到大致相当于半拖车的机架,并且可以部署在路边或蜂窝网络塔的底部。在这背后,电力和冷却等方面的创新将使得越来越高密度的基础设施能够部署在这些占地面积小的数据中心。

IO、EdgeMicro和EdgePresence公司这样的新晋者已经开始在美国少数城市建立这些微型数据中心。2019年是这些微型数据中心的建设元年,年对这些建设的投资将持续加大。到2022年,边缘数据中心的回报率将成为那些对边缘计算进行资本投资的人所关注的焦点,最终这些回报率将反映出一个问题的答案:是否有足够的杀手级应用程序可以让边缘计算如此接近终端用户或设备?

我们很早就得到了这个问题的答案。我最近采访过的一些从业者对接入边缘的微型数据中心是否比区域边缘的区域数据中心更具有足够的边际效益表示怀疑。区域边缘计算已经在许多方面被早期采用者利用,包括各种云卸载案例,以及对在线游戏、广告服务和电子商务等用户体验敏感领域的延迟缓解。相比之下,那些需要超低延迟和非常短距离的接入边缘网络路径的应用程序往往听起来更加遥不可及:自动驾驶、无人机、AR/VR、智能城市、远程手术。更重要的是,这些应用程序必须权衡接入边缘的好处,而不是使用本地或设备上的方法进行本地计算。然而,访问边缘的一个杀手级应用程序肯定会出现——也许这不是今天的焦点。几年后我们会知道更多。

在上文中我概述了边缘计算是如何描述各种体系结构,以及“边缘”可以位于许多地方。然而,这一行业的最终方向是走向统一,走向一个可以使用相同的工具和流程来管理云和边缘工作负载的世界,而不管边缘位于何处。这将需要对用于在云上部署、扩展和管理应用程序的软件进行改进,而云上的应用程序在过去是以单个数据中心为架构的。

Arc和VMware的Tanzu等大公司都在以这种方式发展云基础设施软件。几乎所有这些产品都有一个共同点:它们基于Kubernetes进行开发,这一技术已经成为管理集装箱化应用程序的主要方法。但这些产品已超越了Kubernetes最初支持一个由Kubernetes集群组成的分布式机群新世界的设计初衷。这些集群可能位于由“边缘”、内部部署环境和公共云组成的异构基础设施池之上,但由于这些产品的出现,它们都可以被统一管理。

kubernetes,简称K8s,是用8代替8个字符“ubernete”而成的缩写。是一个开源的,用于管理云平台中多个主机上的容器化的应用,Kubernetes的目标是让部署容器化的应用简单并且高效(powerful),Kubernetes提供了应用部署,规划,更新,维护的一种机制。

最初,这些产品的最大机会将是支持边缘计算发展的第一阶段,即通过一个或多个云利用少量区域的适度分布式部署。但这恰好使它们处于有利地位,可以支持即将来临的更加分布式的边缘计算架构的演进。Rafay Systems的首席执行官Haseeb Budhani最近告诉我:“解决当今多集群管理和操作问题,你就可以在更广泛的边缘计算案例成熟时解决它们。”

如今支持边缘计算的资源正方兴未艾,边缘思维将在设计和支持应用程序的人员中变得更加流行。在一个以计算资源集中在少数云数据中心为典型趋势的时代之后,目前出现了一股支持进一步分散的抵消力量。边缘计算仍然处于非常早期的阶段,但是它已经超越了理论而进入了实践。在如今云计算只有14年的历史背景下,我们能感受到这个行业的发展是如此之快。从长远来看,用不了多久,边缘计算将势必在计算机领域留下浓墨重彩的一笔。

我要回帖

更多关于 customer发音 的文章

 

随机推荐