错了! 使用带内管理,可以让所有管理接口和数据流量共享同一物理接口。 共享的接口可以最大程度地降低系统成本,并使最终用户更轻松,这是为企业部署构建托管服务时的两个关键支柱。 通过统一的带内管理方法可同时满足这两个方面的要求,并简化了服务提供商添加新的VNF功能和增加现金流的能力。
许多商用VNF作为一项附加功能都支持带内管理。 它允许用户配置一个网络连接来处理WAN和管理流量。 通过带内管理,VNF(或运行VNF的裸机物理设备)可以将单个IP地址用于所有面向Internet的通信。 卸载专用管理端口可简化网络设置,降低系统成本,并简化安装过程。 使用专用管理端口的标准带外配置方法是VNF的基本设置,但是带内管理可以有很大的改进。
图1.比较标准和带内管理VNF的配置
当某个VNF是其他VNF的服务链的一部分时,仍然有理由说明为什么可能需要专用的管理端口。 让所有管理流量通过链中的所有VNF是非常不理想的。 配置这样的设置将给服务链中的每个VNF增加不必要的复杂性,而仅用于启用服务链的VNF特定配置将为服务配置创建漏洞。 根据设计规则,所有VNF均应不知道其所属的服务链和底层网络。
图2:VNF服务链结合带内管理的服务链是一个设计问题
此推理强烈支持使用标准的带外方式通过专用WAN,LAN和管理端口配置VNF。 另一方面,带单个接口端口的带内管理可提供更好的用户体验和更低的系统成本。
图3:VNF服务链上没有带内管理的服务链,用于简单的VNF入门
将简化与良好的设计原则相结合,对服务链的网络设置提出了一些严格的要求:
出于成本原因,需要为WAN和管理面共享物理端口。
每个VNF都必须在不感知其所属服务链的情况下进行配置。
使用专用的WAN,LAN和管理端口进行带外网络配置是配置每个VNF的理想方法,因为它是标准配置方法,并且是干净服务链配置所必需的。
这些看似不兼容的要求如何组合起来可能并不明显,但是可以在底层虚拟化层中实施解决方案。
虚拟化平台必须允许其自己的平台级管理流量与用于WAN流量的物理NIC共享。
用于WAN流量的物理NIC也需要与每个VNF管理流量共享。
在单个物理NIC上共享所有管理和WAN流量不会对服务链中的单个VNF配置产生影响。
图4:虚拟化平台应独立于其托管的VNF解决服务链和带内管理
那么,有没有可用的虚拟化平台可提供这种方法来进行统一的带内管理?
是的,Enea NFV Access是uCPE的虚拟化平台,使用一个物理NIC在平台级别为所有管理和WAN流量提供带内管理。 作为零接触配置(ZTP)的一部分,可以轻松实现自动化。 该解决方案可以扩展到任何规模的服务链。 在加入VNF时,不会考虑VNF是否包含在任何服务链中; 带内管理和服务链接的所有网络配置都在虚拟化平台中解决。 Enea NFV Access简化了VNF的注册,支持WAN和所有管理的单个公共IP地址,并提供了真正的通用注册方法,可实现了完全开放和零锁定。
责编:Yvonne Geng