3.6  NFV最佳实践

网络云将提供一组基本功能，可供在服务提供商网络上运行的虚拟功能（VF）使用。网络云将提供并支持主机、主机操作系统、OpenStack、基于内核的虚拟机（KVM）管理程序和虚拟交换机（vSwitch）/虚拟路由器（vRouter）。它还将提供一种环境，允许每台虚拟机（VM）在一台物理服务器上与其他虚拟机隔离开来，仅在自己的分区上运行。第7章描述的 AT&T开放式网络自动化平台（ONAP）框架提供了服务编排以及虚拟功能实例化和配置功能，它在实例化和使用时提供配置管理，从虚拟功能处采集故障、性能、应用关键性能指标（KPI，KeyPerformanceIndicator）并查看数据，根据采集的数据和供应商提供的工程规则来决定执行虚拟功能的自动恢复或自动扩展，将触发新虚拟功能的动态实例化，以便根据需要与服务编排器一起进行自动恢复或自动扩展。该网络主要基于互联网协议第6版（IPv6，InternetProtocolversion6），但能够与基于互联网协议第 4版（IPv4，InternetProtocolversion4）的部件进行交互。

网络云支持各种具有不同性能要求的虚拟功能。所支持的虚拟功能响应时间特征可以划分为以下几类。

（1） 实时是以毫秒 /微秒为单位进行测量所需要支持的响应能力，如会话发起协议（SIP，

SessionInitiationProtocol）查询和响应的低时间阈值。

（2） 近实时是以秒为单位进行测量得出的响应。

（3） 非实时是以分钟、小时或天为单位进行测量得出的响应。

为了确保 VNF能够进行高效互操作，且由于 VNF可以来自多个供应商，因而AT&T编制了

VNF设计的如下最佳实践。

（1）  虚拟功能必须与云平台细节无关（如硬件、主机操作系统、虚拟机管理程序），且必须在共享标准云上运行，并承认云平台将继续快速发展的范式以及平台单层网络部件将会定期发生改变的事实。

（2） 虚拟功能设计必须使用基于云的范式来实现技术标准化、可扩展性和可靠性。

（3） 必须支持网络功能的分解。

（4）  必须支持重用虚拟功能的能力，以便将基于服务需求的虚拟功能进行链接以快速创建服务。

（5） 持久状态和最终用户（订户 /客户）数据应与处理逻辑分离开。

（6） 虚拟功能应支持地理弹性以及使用本地和地理冗余进行部署的能力。

（7）应尽可能支持通用平台解决方案（如基于云的负载均衡器、数据库、弹性解决方案等），而非供应商专有解决方案。

（8）虚拟功能必须支持故障、配置、计费、性能和安全（FCAPS，FaultConfigurationAccounting

PerformanceandSecurity）功能的标准化机制。

（9） 虚拟功能设计应当满足服务的弹性、可用性和性能（如实时响应）要求。

（10） 向基于云的设计过渡应当对最终用户透明。

（11） 虚拟功能必须能够通过ONAP功能进行实例化和控制。虚拟功能或其部件不应直接与

OpenStack架构进行交互。

（12） 必须支持开放和标准 API，应在所有可能情况下实现幂等接口。

（13）虚拟功能应在不修改标准客户操作系统映像的情况下运行，应当有条件支持供应商提供的客户操作系统映像。

致谢

笔者要感谢 ChrisChase对本章内容的贡献