转载

容器化ICT融合初体验

容器化ICT融合初体验

2015年,NFV和容器无疑都是最热门的技术,被很多业内人士认为是未来的发展趋势,2016年,当NFV遇上容器,会碰撞出什么新的火花?当容器化的CT/IT业务在同一平台内融合部署,又会产生怎样新的体验?下面和大家大家分享一下,从2015年到2016年,我们做的容器化CT-IT融合方面的工作。IT我就不解释了,CT这里主要指的是电信业务。

容器化CT-IT融合系统是一种面向未来ICT系统的新型云计算PaaS平台,它基于容器这一轻量级的虚拟化技术以及自动化的微服务管理架构,能够有效支撑应用快速上线和自动扩缩容,最大化IT基础设施资源利用率并降低总体TCO。未来的网络正在向IT化、云化方向发展,容器与微服务技术,完美契合“网络即服务”、网络切片等发展理念,将有助于实现更加灵活、智能、高效和开放的5G新型网络。

下面是从2015年到2016年,我们做的容器化CT-IT融合方面的工作:

- 2015年,我们首次提出容器化ICT融合方案

- 2016年初,我们完成容器化ICT融合原型系统

- 2016年4月8日~4月9日,中国移动召开2016年度技术工作会,容器化ICT融合原型系统首次亮相技术工作会精品展。

- 2016年6月20日~6月23日,OPNFV Summit在德国柏林召开。在OPNFV PoC战区,中国移动和红帽公司联合展示了容器化ICT融合平台

- 2016年6月29日,由GSMA主办的2016世界移动大会-上海(Mobile World Congress,简称MWC)在上海新国际博览中心盛大开幕,在中国移动研究院5G展区,我们为参会专家演示了容器化ICT融合原型系统。

最初产生将网元容器化的想法来源于2015年,我们正在进行NFV IMS测试,同时也正在进行容器和DCOS的相关技术研究和验证性工作,关于应用场景,最适合容器化的应用无疑是所谓的云原生应用,或者说是微服务,其主要特点是分布式、无单点失效、无状态,这和我们测试的某些厂商的IMS网元的特征竟然如此地一致,而容器的轻量级、高性能、快速启动等优势,也恰好是网元所需要的,几分钟部署一套核心网元或许真的会从梦想变成现实。于是,一对新的组合诞生了,NFV Container=NFC。

理论+实践才能创造出真理,在理论分析的基础上,可行性验证必不可少,而惊喜总是无处不在,尝试创新的道路也不是总那么孤独,开源的IMS项目Clearwater也在做和我们类似的工作。Clearwater是IMS网元的一个开源实现,其主要目标是开发一套适合在云上(如aws)部署的IMS网元,提供语音、视频、消息服务。Clearwater在架构上就以微服务的方式设计各个组件,并且提供了docker格式的容器镜像,我们将它移植到Kubernetes平台上,平台具有负载均衡、容灾恢复、支持资源监控等特点使其更适合服务化

测试环境

- 硬件

• Red Hat 3D打印演示系统,内含3台服务器

容器化ICT融合初体验

  • 软件

    • 操作系统:Red Hat Enterprise Linux Server release 7.2 (Maipo)

    • 容器引擎:docker-1.8.2-10.el7.x86_64

    • 容器编排:kubenetesv1.1.0-origin-1107-g4c8e6f4

容器化ICT融合初体验

  • Clearwater架构

    Clearwater架构主要分为六大组件,Bono、Ralf、Sprout、Homer、Homestead、Ellis,如下图所示,其中Sprout作为SIP Router,是核心业务处理模块,也是业务量增加时,需要做动态扩容的主要部分。

容器化ICT融合初体验

NFC测试方案

针对clearwater中每个组件,定义一个kubernetes service,每个服务中包含一个或多个POD,可以通过增加POD个数进行横向扩展。

Kubernetes中服务列表如下图所示:

容器化ICT融合初体验

kubernetes中POD列表如下图所示。测试过程中,通过基于SIPP的clearwater组件增加并发用户量,系统压力增加,触发sprout服务中POD个数增加。

容器化ICT融合初体验

为实现POD的动态扩展,一方面,利用kubernetes本身的replication controllers,根据负载增加或减少POD副本数量,另一方面,clearwater sprout是微服务架构,分布式,无状态,数据和应用分离,可通过集群配置,让集群中各个容器共享数据库。

在并发用户数为300个时,sprout模块POD数量一般为2~3个,在并发用户数增加到2000个时,sprout模块POD数量达到11个,如果继续增加并发用户数到3000个,sprout模块POD数量达到15个左右。

CT-IT融合测试方案

在大数据应用中,容器的轻量级、高性能、快速启动等特点同样具有优势,而CT和IT业务融合部署,也是未来发展的一个趋势,在本次测试中,我们在同一个容器平台上,部署了IMS网元和大数据应用。

在CT应用负载比较低的时候,系统主要用于进行大数据应用计算,大数据应用所占系统CPU资源比例较高。如下图资源监控界面所示。

容器化ICT融合初体验

当CT业务量增加,系统负载增大,为满足在线CT业务要求,增加CT业务容器数量,同时减少大数据离线业务占用资源。资源使用情况变化如下图所示。

容器化ICT融合初体验

总结

容器作为轻量级的虚拟化技术,可以降低系统开销,提升系统性能,

  • CT/IT融合部署:CT和IT应用在同一平台内混合部署,共享资源,提高资源利用率。
  • 统一资源调度:打破应用竖井,统一建设,统一运维,降低TCO
  • 系统性能提升:采用容器技术,轻量级的虚拟化,降低系统开销
  • 微服务架构:分布式、无状态的云原生应用,实现应用于数据的分离
  • 弹性伸缩、自动扩容:支持自定义的资源调度策略,实现根据业务量变化的资源动态调度。

Q&A

Q:网络转发有没有遇到瓶颈?有没有尝试一些加速技术,比如DPDK?

A:因为是控制面网元,目前没有遇到瓶颈,没有用DPDK,我们之前测试过虚拟机的,因为网元特点,也是没有配置DPDK,目前的测试上看,性能上没有问题。

Q: 现在数据库也放在容器中吗? 谢谢

A:是的,但是也是数据库集群,我们正在做将数据库分离的工作

Q:你们实测的容器运行于虚拟机环境,性能如何,你们容器网络如何实现NFV互联?

A:容器没有基于虚拟机环境,因为是控制面网元,性能没有遇到瓶颈。

Q:容器不会包打天下,与虚机,物理机并存可能是一段时间内的一种常态,我们有没有分析哪些业务适合容器化,哪些业务不宜改变?并且在利用k8s作为容器的编排调度工具时,如何实现容器与虚机应用的互通?

A:其实业务不宜改变不仅仅是技术问题,也和业务厂商是否愿意改变有关,毕竟一些遗留的业务已经在现网运行很久了,很难短期内容器化。另外,我们确实碰到了需要内核优化的业务。我们系统中还没有做容器和虚拟机应用互通

Q:传统CT网络不仅仅是ims吧,对于cs、ps,sdn/nfv化,你们有什么思路吗?

A:IMS使我们容器化的第一个尝试,其他的网元也正在研究中,后续也会做相关的测试,如果有兴趣,也欢迎参加我们后面的测试

请问一下:nfvi 是基于哪种开源方案实现嘛?资源池化,每个机器都需要安装客户端的嘛?

A:在我们的方案里,docker相当于NFVI

Q:在PAAS 云平台控制下 对传统双机节点是怎么考虑部署的,还继续采用双机软件实现倒换吗,还是直接由云平台控制实现自动迁移,或者是否还存在传统的双机应用模式 这块怎么考虑的,2 应用横向扩展伸缩的时候,完全由pod 控制吗,对于传统由自身业务实现的伸缩 是否需要应用完全将伸缩控制权交给POD?

A:目前是测试的网元是分布式架构。在我们的系统中,是交给POD,当然,对于一些复杂网元,存在网元需要控制的情况

Q:你们的资源池,有路由器,安全组,负载均衡之类的功能嘛?路由器,负载均衡器可以被分配公网IP嘛

A:指的是容器的资源池还是我们已有的私有云资源池,已有的私有云资源池是有的,但是容器这个原型系统还没有

Q:类似clearwater的开源项目还有哪些?

A:NFV方面的吗,如果是IMS,clearwater业界用的比较多,NFV其他网元开源项目很多

Q:你们的虚拟机底层使用什么虚拟化技术支撑?

A:这次演示,底层用的就是docker,我们的私有云资源池有vmware、kvm也有xen

Q:容器化应用适合于状态无关且无连接的场景,核心网容器化,会话共享是业务最核心的,请教下你们实践如何解决这个的呢,帮忙介绍下呗

A:我们正在研究有状态业务的容器化,也是因为确实有些网元是有状态的

原文  http://dockone.io/article/1636
正文到此结束
Loading...