前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >vCPE 2.0——开放vCPE架构的业务用例

vCPE 2.0——开放vCPE架构的业务用例

作者头像
SDNLAB
发布2018-03-30 12:19:19
8920
发布2018-03-30 12:19:19
举报
文章被收录于专栏:SDNLABSDNLAB

目前已经有大量的文章在描述虚拟CPE(vCPE)的优势,简化企业广域网(WAN)的复杂性激发了许多网络工程师和企业IT管理员的想象力。能够通过自助服务门户和自动化来消费、配置和管理WAN及其服务的愿景使得vCPE成为最常见的网络功能虚拟化(NFV)用例。

另一个主要驱动因素是通过使用低成本CPE设备和网络服务节省成本。对于通信服务提供商(CSP)来说,它能够创建灵活的服务。自动化服务创建并实现资产的虚拟化。

看起来这个计划非常完美,然而当我们开始部署这些解决方案时,我们意识到现实更加复杂。此外,vCPE服务在某些情况下无法实现成本节省,甚至会更昂贵,且质量更差。

在本文中,我将尝试揭开vCPE的成本模式,并提供一种替代方法来构建一个更具成本效益和创新的vCPE解决方案,并提供CSP为保持相关性所需的灵活性和适应性。

为了更好地理解CPE成本模型并向vCPE演进,我们看一下传统WAN服务是如何交付的。WAN服务围绕三个要素构建:CPE、网络和提供服务的电信公司。价格是基于CPE设备中内置的服务功能、价值和可靠性以及相关的网络连接、带宽和服务而定。因此,可靠的服务的企业必须投资昂贵的CPE设备和可靠的网络服务(MPLS)。

这是模式:服务(CPE+网络)x站点数=每个站点每月的总成本,网络指类型(如MPLS)、带宽和服务(如MPLS V**)。

架构如下:

Photo Source: Gigaspaces

回顾2012年,NFV的出现并向vCPE演进,当时想法非常简单:转移功能、价值和成本……

☘ 从网络边缘到云端

☘ 从硬件到基于软件的功能

☘ 从MPLS到OTT网络和网络接入

☘ 从劳动密集型交付到自助服务和自动化

新架构如下:

Photo Source: Gigaspaces

为什么我们没有获得预期的成果?

我们将探讨在这个演变过程中三个主要解决方案的元素发生了什么变化。

CPE

价格下跌且市场商品化正在进行。然而,我们还不能通过50美元的白盒机提供类似于传统CPE的功能,主要网络厂商不支持这种演进,事实上通过将服务与特定的专有CPE设备绑定很困难。

网络

大多数vCPE解决方案利用OTT网络,例如软件定义广域网(SD-WAN),理论上是降低了带宽成本。随着企业提供来自非传统服务提供商和网络厂商的OTT网络解决方案,传统的CSP将被迫采用这种技术并占据现有的广域网收入。

云计算/VNF

这是一个极具挑战和误解的问题,在提供积极的服务体验的同时运行虚拟网络功能(VNF)既昂贵又复杂。

构建企业WAN服务需要提供以下网络功能:

☘ 路由堆栈

☘ 安全和统一的威胁管理

☘ 服务质量

☘ 应用程序可视化

☘ 内容管理

☘ 等等

在专用硬件上构建其解决方案的窗台网络供应商被迫快速采用软件模式。大多数供应商通过简单的提供“虚拟设备”采取了简单的方法,这与硬件解决方案有相同的代码库,并在管理程序上的软件中运行。这些虚拟设备中的大多数与硬件具有相同的特性:

☘ 封闭或专有管理接口

☘ 缺乏服务和弹性性能

☘ 传统的成本模式和许可

☘ 重虚拟化足迹

我们再次将这些元素放入我们的成本公式:服务(CPE+网络+VNF)x站点数=每个站点每月的总成本。

将VNF元素添加到成本公式是极具挑战性的,并且在很大程度上被曲解。要了解VNF的实际成本,我们需要考虑以下内容:

☘ VNF许可

☘ 虚拟基础设施(CPU、RAM、存储)

☘ 管理和编排

第一代vCPE解决方案由传统网络供应商推动turnkey解决方案,他们的解决方案为COE提供网络设备、VNF和业务流程架构,这些解决方案具备如下优势:

☘ 更快的上市时间

☘ 降低前期成本

☘ 开放的API

☘ Turnkey集成

Turnkey=Lock-in

第一代vCPE解决方案都有不好的一面:锁定(Lock-in)。Turnkey vCPE解决方案只是一种封闭且昂贵并且严格锁定厂商收入模式的网络盒子。我们最终得到了一个CPE商品化和OTT网络节省超过传统VNF成本增加和运行它们所需的基础设施的解决方案。

Photo Source: Gigaspaces

前瞻性思考

正如Nati Shalom在之前的SDxCentral文章中所写的,开放是发展的方向,我仍然相信集中网络功能和价值是建立vCPE模式和成本节省模式的正确方法。但是,实现这一目标的唯一方式是使用创新的云本地功能,下一代vCPE将建立在以下网络功能的基础上:

☘ 基于标准和模型驱动

☘ 服务和弹性容量

☘ API驱动

☘ 开放和可扩展

☘ 使用成本节省的云模型

早期的开源选择

vCPE架构是由开源的cloudify支撑的,是一个开放的NFV编排平台,使得CSP能够根据这些原则提供下一代vCPE解决方案。CSP可以利用任何CPE设备,使用任何网络服务,利用搭载的VNF构建vCPE解决方案。下一代云本地网络功能市场正在快速增长,我们在传统基础设施和许可下使用的功能已经能够提供部分增强的服务,容器技术也逐渐广泛应用于网络功能。

Photo Source: Gigaspaces

未来的vCPE模式

开放的vCPE架构强调编排和模型驱动的服务设计。这与设计成为自下而上的Turnkey解决方案截然不同,后者从堆栈组件开始,并构建一个仅与这些组件一起使用的编排架构。Cloudify模式驱动的拓扑和编排规范的云应用程序(TOSCA)的编排采用自上而下的方法。它假定服务的组件将随时间而改变,但服务和编排的方式不会改变。

有以下几个有点:

☘ 轻松采用新技术(VNF)

☘ 服务敏捷性

☘ CSP服务差异化

☘ 增强用户体验

☘ CSP解决方案所有权

为什么运营商需要开放的vCPE架构

在商业上,成功的模式必须采用一个能够驱动所有解决方案元素(包括CPE、网络和VNF)的架构,实现成本降低。他们必须快速拥抱创新,以抓住CSP从中获益的新机会、能力和模式。构建未来网络的唯一方法就是保持开放。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2017-02-03,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 SDNLAB 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
容器服务
腾讯云容器服务(Tencent Kubernetes Engine, TKE)基于原生 kubernetes 提供以容器为核心的、高度可扩展的高性能容器管理服务,覆盖 Serverless、边缘计算、分布式云等多种业务部署场景,业内首创单个集群兼容多种计算节点的容器资源管理模式。同时产品作为云原生 Finops 领先布道者,主导开源项目Crane,全面助力客户实现资源优化、成本控制。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档