NFV容器之路就在脚下?


【编者的话】网络功能虚拟化(NFV)是开放网络能力的必经之路,目前主流的方式是通过OpenStack的编排能力实现NFV的快速自动化部署。随着容器技术的快速发展,容器编排能力也在飞速提升,通过容器实现NFV是大势所趋,但前进之路崎岖蜿蜒。路漫漫其修远兮,吾将上下而求索,各大厂商在NFV容器化之路上披荆斩棘,取得了不小的进展,这篇文章就是介绍Red Hat的NFV容器化相关的思考。

【上海站|3天烧脑式微服务架构训练营】培训内容包括:DevOps、微服务、Spring Cloud、Eureka、Ribbon、Feign、Hystrix、Zuul、Spring Cloud Config、Spring Cloud Sleuth等。

网络功能虚拟化(NFV)在电信行业和大企业中被广泛采用。NFV的初衷很简单:将之前运行在专用设备上的网络能力虚拟化,并使其运行在通用型服务器硬件上。使用通用型计算基础设施的规模经济效益,至少在原理上远远超过使用专用设备。

通常我们所说的NFV部署指的是在虚拟机中运行网络功能,例如在基于内核或者ESXi的虚拟机上运行网络功能虚拟化,更LOW一点的做法就是在Hyper-V虚拟化层上运行。虚拟机(VMs)提供与主机操作系统完全的隔离,但是性能也会有一定的损耗。尽管较新的一些技术能够减轻内核的工作负载,比如DPDK(Data Plane Development Kit)和SR-IOV(Single Root Input/Output Virtualization)。但是即使是使用支持企业级通信的数据包,并保持高吞吐量性能的情况下,一台物理主机上的虚拟机数量仍然受到限制。

接下来的问题就是,这些网络功能能否被容器化,以满足微服务的模型?容器化之后的网络功能,其性能是否比虚拟机更好?这些容器化的网络功能的扩展性如何?诸如此类的问题还很多。

我们先简要地回顾下什么是容器化。容器化是一个轻量级的机制来实现进程隔离,以便于限制其与指定的资源进行交互。容器在Linux中早已存在,只是最近由于开源项目Docker才变得流行起来。通常每个容器提供单个服务。例如,在NFV环境中,单个服务可以被认为是在容器中运行动态主机配置协议(DHCP)服务器,或者网络地址转换(NAT)功能。您可以运行多个NAT容器,每个客户/租户一个容器为虚拟专用网路(VPN)里面的设备提供网络地址转换能力。

目前为止已经完成的一些POC(proof-of-concept)表明,网络功能容器化之后,通过Linux容器(LXC)、Docker或者Rocket(另一种Linux容器)来运行,相对于通过虚拟机运行优势是非常明显的。然而,当规模较大的时候,结果就很差强人意。例如,一个提供商希望为每个服务器部署超过1000个虚拟客户端设备(vCPE)容器,但在测试中几乎无法达到100个。

我相信某些网络功能通过容器化的形式更好,但是其他的某些功能仍然适合通过虚拟机部署。谈到容器,我们才刚开始研究,但是通过虚拟机部署,我们已经至少两年前就开始了。对于容器化某些特定网络功能还是抱有极大兴趣的,比如vCPE、NAT、个人防火墙、应用防火墙、IP地址管理,甚至是控制层面的一些功能,比如基于LTE(VoLTE)网络的IP多媒体子系统(IMS)/语音的呼叫会话控制功能(CSCF)。这其中的一些工作正在进行中,可能越来越多的供应商会首先将其容器化,然后对容器的性能进行调优。

Red Hat从Red Hat Enterprise Linux 6.0开始支持Linux容器,差不多六年了。OpenShift是Red Hat的平台即服务(PaaS),是默认的容器管理引擎。最近发布的OpenShift 3.0,Red Hat增加了对Docker容器的支持。红帽还与一些大型服务提供商合作,尝试和运行概念验证(POC)容器化NFV用例,如IMS VoLTE和vCPE。随着这一变化,我希望读者能够了解NFV和容器的进展,也许可以提供有关未来容器上VNF性能的详细文章。

现在容器化是NFV的一个有趣的概念,它仍处于实验阶段。在接下来的12个月中,将有更多的POC和试验将提供有价值的反馈,以提高NFV容器的性能。并不是网络功能容器化本身阻碍了NFV中的微服务,而是容器的性能和规模。随着性能和规模的提高,VNF容器将会被更广泛地采用。

在此期间,您可以参加本周的旧金山Red Hat Summit 2016,了解有关容器,NFV和VM性能的很多信息。

原文链接:Is NFV ready for containers?(翻译:付辉)

0 个评论

要回复文章请先登录注册