容器化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台服务器
-
软件
• 操作系统:Red Hat Enterprise Linux Server release 7.2 (Maipo)
• 容器引擎:docker-1.8.2-10.el7.x86_64
• 容器编排:kubenetesv1.1.0-origin-1107-g4c8e6f4
-
Clearwater架构
Clearwater架构主要分为六大组件，Bono、Ralf、Sprout、Homer、Homestead、Ellis，如下图所示，其中Sprout作为SIP Router，是核心业务处理模块，也是业务量增加时，需要做动态扩容的主要部分。
NFC测试方案
针对clearwater中每个组件，定义一个kubernetes service，每个服务中包含一个或多个POD，可以通过增加POD个数进行横向扩展。
Kubernetes中服务列表如下图所示：
kubernetes中POD列表如下图所示。测试过程中，通过基于SIPP的clearwater组件增加并发用户量，系统压力增加，触发sprout服务中POD个数增加。
为实现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资源比例较高。如下图资源监控界面所示。
当CT业务量增加，系统负载增大，为满足在线CT业务要求，增加CT业务容器数量，同时减少大数据离线业务占用资源。资源使用情况变化如下图所示。
总结
容器作为轻量级的虚拟化技术，可以降低系统开销，提升系统性能，
- 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：我们正在研究有状态业务的容器化，也是因为确实有些网元是有状态的
正文到此结束
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
