37

解密NFV:互操作性和API之间不得不说的关系

 5 years ago
source link: https://www.sdnlab.com/22861.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

几年前,网络功能虚拟化(NFV)成为了网络领域最热门的话题之一,其承诺会带来动态虚拟网络并节约成本,目前大多数主要网络运营商正在进行调查和试验。然而,NFV还没有达到我们所预期的爆炸性增长和预期收益,这已经不是什么秘密了。为了实现NFV的承诺,需要提高厂商解决方案之间以及这些解决方案中各个组件之间的互操作性。

nfv-api-interopera-668x400.jpg

NFV的问题从来都不是缺乏解决方案,而是解决方案太多,这些解决方案独立于NFV环境的特定组件运行而没有互操作性。运营商接受了厂商的炒作,并测试了来自多个厂商的多种工具。目前的实际情况是,NFV解决方案由多个工具组成,以涵盖网络运营商所需的所有用例。

为了解决这个问题,首先需要探讨NFV目前面临的问题以及它是如何走到这一步的。迄今为止,NFV在兑现其承诺方面进展缓慢,主要原因是已经引入的众多工具之间缺乏互操作性。我们没有实现为现有OSS系统提供集成点的单个NFV Orchestrator,以及单个VNF Manager和单个Virtual Infrastructure Manager(VIM)与NFV Orchestrator交互的愿景,而是利用NFV的特定用例,例如SD-WAN和虚拟CPE(vCPE)已经引入了多个编排器,多个VNF管理器,并且通常是混合云模型,这导致整个栈中的管理工具成了大杂烩。

NFV的挑战实际上是从基础设施的最底层开始的。在早期,NFV使用的主要环境是 OpenStack。不幸的是,许多公司已经在VMware基础设施上投入了大量资金,这对早期的NFV试验带来了一些挑战。这些现有的VMware环境更适合IT使用的虚拟服务器和软件,例如电子邮件服务器和其他传统IT系统。与OpenStack相比,由于对VMware投资的减少以及缺乏NFV适用性,出现了同时包含OpenStack和VMware的混合环境。这意味着管理系统之间的决斗,包括每个附带的管理工具。基于容器的基础设施和其他管理工具的引入进一步加深了这种混合环境的复杂性。再加上AWS,Azure和Google的所有公共/私有云,庞大的管理工具变得愈加难以有效管理。

VNF管理层也存在问题。VNF Manager编排虚拟网络功能(VNF)的活动,例如虚拟路由器、交换机和负载平衡器。对于每个将VNF引入市场的厂商,至少也会引入一个VNF Manager。这可能是一种新工具,或者它可能是现有管理系统的新版本,用于为VNF修改的物理网络元素。最重要的是,包含NFV Orchestrators的业务流程层也从厂商那边获得了许多选择。有时它们与VNF Managers一起打包,有时它们是由另一个厂商提供的独立编排器。

问题很明显。公司必须管理NFV环境,其中包括NFV Orchestration和VNF Management层中的多个编排工具以及3-5个基础设施管理器,每个管理器处理其混合云架构的特定部分。其中的每一部分都由不同的厂商提供,它们之间几乎没有什么互操作性。这些多NFV管理系统还必须与现有的网络管理工具集成。

互操作性是NFV的关键

互操作性对于NFV的采用至关重要,原因有两个。第一个原因是与人员有关。如上所述,NFV环境需要多个新工具。使用者需要全部了解它们并手动从一个系统转到另一个系统,以执行每个系统所需的特定任务。这里存在着一个巨大的技能差距问题。有的工程师无法学会有效地使用每一个工具,因为工具太多了。这将导致团队内部专门化,让某些工程师专门来管理工具子集。因此,一个工程师可以完成的任务可能涉及多个人才能完成。为了实现NFV简化和削减成本的目标,运营商正在构建一个复杂的环境,需要更多人才能获得成功。

其次,从网络管理的角度来看,如果服务的定义分散在无数个不同的系统中,而没有一个系统具有完整的视图,那么维护这些服务是很困难的。这直接影响到管理配置变更、准确地向最终用户(无论是内部还是外部)收取所使用服务的费用,并有效监控和确保网络的质量、性能和可靠性的能力。所涉及的每个系统的数据联合是互操作性的一个关键方面。必须有一种方法可以查看有关NFV环境支持的服务的所有数据的单个视图,但不能通过创建数据副本来做到这一点。

管理这么多不同组件非常复杂,几乎是一项不可能完成的任务,这也是NFV采用的主要障碍。但是,希望还是有的!由于这些不同的解决方案主要是在过去6到8年内开发的,因此它们在设计时充分考虑了API的功能。这为通过智能网络自动化解决这一问题提供了基础。

NFV的希望?API

现代网络将包括基于NFV的网络和服务。现代网络的关键概念之一是可编程性。可编程性意味着可以以与我们多年来集成软件系统的方式非常相似的方式访问工具和网络本身。基于开放标准的统一API允许跨多厂商环境进行通信,并且能够有效地抵御网络的未来威胁。

每个网络都有多个编排器、控制器和其他网络管理系统。通过使用这些系统的API并呈现一个单个的、统一的管理层,以公开其用于智能网络自动化工作流程的功能,从用户中抽象出复杂性。这种抽象通过消除工程师必须了解添加的10+新系统的需要来消除之前提到的技能差距。相反,该工程师使用的是单一的工具,不仅可以将NFV工具的功能组合到一个共同的用户体验中,而且还可以引入在NFV之前使用过的现有工具。结果不仅仅排除了新的复杂性,而且还消除了现有的复杂性。此外,这种方法可以联合来自每个NFV管理工具和现有网络管理系统的数据,从而提供网络的单一视图。

智能网络自动化和API优先的方法是使NFV能够兑现其众多承诺的答案。这些方法提供了当前不存在的互操作性,从而填补了想要NFV成功所缺少的环节。


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK