虚拟机和容器超融合试验研究

吴金坛 陈路路 李智鑫

1(中国银联电子支付研究院 上海 201203)

2(复旦大学计算机科学技术学院 上海 200433)

0 引 言

当前，云计算已是金融机构运用金融科技打造现代化运营的基础，越来越多的金融机构将实施云计算解决方案作为科技战略创新的第一步，建立金融数字生态，金融行业已经形成了“上云刻不容缓”的共识，不仅是大金融机构，越来越多的中小金融机构对上云的需求也变得更加迫切[1]。随着金融机构面向互联网业务的迅速发展，数据中心云平台规模及资源需求不断提升，云计算平台上的资源能否高效调度已上升为关键技术问题，解决好云资源高效调度问题，也就解决了企业的云资源快速供给问题。

虚拟化资源是云平台的主要资源服务模式，因此虚拟化技术是云平台的核心关键支撑技术。虚拟化技术将整个数据中心的计算资源统一抽象出来，形成可以按一定粒度分配的计算资源池。通过虚拟化技术的应用，数据中心可以具备更高的应用密度，从而在等量资源情况下能够为更多的用户提供服务。

1 背景介绍

1.1 虚拟化技术介绍

虚拟机和容器是当前主流的虚拟化技术[2]。虚拟机(Virtual Machine，VM)指通过软件模拟的、具有完整硬件系统功能的、运行在一个完全隔离环境中的完整计算机系统。虚拟机技术最早由IBM于二十世纪六七十年代提出，其中虚拟机监视器(Virtual Machine Monitor，VMM)是虚拟机技术的核心，它是一层位于操作系统和计算机硬件之间的代码，用来将硬件平台分割成多个虚拟机。VMM运行在特权模式，主要作用是隔离并且管理上层运行的多个虚拟机，仲裁它们对底层硬件的访问，并为每个客户操作系统虚拟一套独立于实际硬件的虚拟硬件环境(包括处理器、内存、I/O设备)。容器技术则是一种沙盒技术，可以将应用运行在其中，与外界隔离，这个沙盒可以被方便地“转移”。本质上，容器就是一种特殊的进程。通过在创建容器进程的时候，指定了这个进程所需要启用的一组命名空间(Namespace)参数，进而让该容器进程只能看到当前Namespace所限定的资源、文件、设备、状态或配置。

经过多年发展和优胜劣汰，目前主流的虚拟机技术是KVM硬件虚拟化技术，主流的容器技术是docker容器，其架构分别如图1和图2所示。虚拟机虚拟化包括硬件虚拟化技术和指令集虚拟化技术，此处以硬件虚拟化技术为例说明。

图1 虚拟机虚拟化架构图

图2 容器虚拟化架构图

在图1所示的虚拟机虚拟化架构图下，每个虚拟机在Hypervisor的管理下拥有自己独立的客户操作系统，互不干扰，在每个客户操作系统之上可以运行独立软件和应用。而容器则在Docker引擎的控制下，直接运行在宿主机的操作系统之上，多个Docker可以共享主机操作系统。相比之下，虚拟机架构安全，隔离性强；容器则轻便，开销小，易于快速部署。

1.2 虚拟机和容器应用场景

虚拟机管理程序直接与宿主机硬件对接，虚拟机的操作系统和应用程序构成了一个单独的环境，与物理机能力相同，同时应用从物理机迁移到虚拟机的过程简单，安全性有保障。虚拟机高度发展，技术成熟，因此企业普遍把虚拟机方案作为其核心业务的首选方案。

但是随着技术的演变，容器方案也取得了一席之地。随着微服务架构发展，软件应用解耦为小功能，而容器能够将软件分离开来，使得应用程序更快地进行创建，更易于维护。在私有云数据中心中，借助私有云的安全内控机制，在不用多考虑安全隔离的场景下，容器可以更好地服务于密集打包部署应用。同时，容器仅对应用实例进行隔离，资源开销更低，大规模部署下更能节省计算资源成本[3]。

基于虚拟机和容器的技术各有优势[4-5]，可以预见，虚拟机与容器未来在云数据中心环境内必然是共同存在的，如何实现虚拟机与容器的共融部署是当前云平台建设的关键研究方向，分析虚拟机与容器如何融合部署和实现高效调度正是本文要解决的问题。

2 当前融合方案

当前的数据中心所采取的虚拟机和容器技术融合方案可以分为两大类，第一类是容器运行于虚拟机之上，第二类是将容器和虚拟机分别运行在不同物理服务器上。

2.1 虚拟机中运行容器

容器运行于虚拟机方案的基本架构如图3所示。

图3 虚拟机中运行容器架构图

在此架构下，虚拟机监视器(Hypervisor)运行于物理服务器之上，物理服务器资源被分配给多台虚拟机，在虚拟机之上运行Docker容器引擎，实现一台虚拟机上运行一个或多个容器，由虚拟机为容器提供资源。国内企业如云南云电同方科技提出的虚拟机和容器融合的混合架构[6]，国家电网公司信通部设计的与服务器相适应的容器虚拟化框架[7]，国外企业如Google和Amazon等主流服务提供商的云计算虚拟融合系统，均采取该类方案[8]。

2.2 虚拟机和容器逻辑并存

第二种方案是将虚拟机和容器在物理资源层面分开，前端提供统一资源请求接口，根据资源请求对任务进行分发至不同的物理服务器，基本架构如图4所示。

图4 虚拟机和容器逻辑共存架构图

这种架构下，前端用户可以在统一资源申请界面上申请虚拟机资源或容器资源，而后台会将请求分发给对应的服务器来处理请求。如中国银联公司采用独立的物理资源池部署，虚拟机专用部分物理资源，容器专用另外的物理资源，相互独立，虚拟机由OpenStack[9]管理，容器由Kubernetes[10]管理，两个开源工具均直接部署在物理机之上。

2.3 当前融合方案优缺点分析

第一种融合方案在虚拟机中运行容器利用了两者技术的优势，容器中的应用既实现了轻量化，又能有良好的隔离性，但效率受到很大影响：(1) 需要创建虚拟机，在创建虚拟机时要预估虚拟机容量；(2) 容器删除时，释放的资源被虚拟机保留着，不能回收利用；(3) 开发人员还需要对容器运行的虚拟机环境进行管理。

第二种融合方式仅是在逻辑层面的融合，是一种“逻辑共存，物理隔离”的融合方案，对用户而言虽然可以享受到虚拟机和容器的服务，但在物理层面，虚拟机和容器并没有融合，存在以下问题：(1) 调度不够灵活，虚拟机和容器智能调度仅能在各自指定的服务器上运行；(2) 未能实现虚拟机和容器资源的相互弹性使用，虚拟机或容器各自的资源的总量是由各自分配给的服务器量所决定的；(3) 资源利用率低，分配给虚拟机和容器的服务器都要超过业务需求，以防止突发大量访问。

总体而言，这两种方案虽然有各自的优点，但对资源的利用率都不够高。

3 虚拟化超融合技术方案

3.1 设计思路与架构

1) 虚拟化超融合方案设计思路。针对上述方案一中容器部署在虚拟机上所造成的性能损耗问题和方案二中虚拟机和容器物理隔离导致数据中心内出现资源墙的问题，探索出一种新的虚拟机与容器融合的方案，其主要设计思路如下。

(1) 虚拟机与容器可共存于同一物理节点，且容器直接运行于物理机之上，虚拟机与容器共享物理机资源，减少性能损耗。

(2) 实现底层资源池统一管理，由云计算的IaaS层对虚拟机与容器资源进行统一分配，实现异构资源的联合调度，打破数据中心资源墙。

(3) 实现容器编排，在云计算的PaaS层对容器进行统一编排管理，从而充分发挥容器的优势。

2) 虚拟化超融合架构。云计算从服务层次上可以划分为三层，分别为IaaS层(基础设施服务)、PaaS层(平台服务)和SaaS层(软件服务)，本方案架构涉及前两个层面，分别是Iaas层的资源统一管理调度和Paas层的容器编排。

(1) IaaS层：资源统一管理调度。IaaS层的融合架构如图5所示。云资源管理平台构建一个统一的物理资源池，对计算、网络、存储等资源进行统一纳管。虚拟机和容器分别由各自的管理组件创建，所有资源请求全部由资源调度协调器进行审核，并筛选出满足要求的物理机节点进行分配。镜像由云资源管理平台统一提供。虚拟机和容器生命周期结束后，由云资源管理平台把资源释放回资源池。

图5 统一资源调度图

(2) PaaS层：容器编排。构建PaaS层的融合架构如图6所示。容器编排有多种方案[11]，IaaS层完成了对虚拟机和容器的生命周期管理，PaaS层则进一步融合实现对容器的编排能力。通过副本管理、标签管理、接口管理等服务组件，将分布在不同物理节点、松散结合的容器进行逻辑化的组织，形成相关功能集群，以实现负载均衡、扩容缩容、灰度升级及故障冗余等能力，集群容器编排的相关算法也是值得探究的方向[12]。

图6 容器编排架构图

3.2 虚拟化超融合解决方案

基于上述方案架构，采用开源技术框架进行了实现。IaaS层采用OpenStack为底层资源管理工具，PaaS层采用Kubernetes为容器编排工具，整体技术框架如图7所示。

图7 整体技术框架示意图

在实现过程中，单纯采用开源的原生方案无法满足一些核心功能点，主要问题如下：(1) OpenStack中的Zun组件虽然可以创建容器，但是在资源管理上，原生OpenStack并没有实现虚拟机与容器资源信息的互通共享，从而出现虚拟机与容器之间的资源竞争问题，因此必须在IaaS做到虚拟机与容器资源的统一协调分配。(2) 本文方案采用OpenStack的Zun来创建容器，而上层又需要Kubernetes对容器进行编排，因此必须对两个平台的相关组件进行对接。另外，Zun与Kubernetes在对容器操作的时候，各自采用了不同的管理模型，因此对接过程中还需要对两种不同的管理模型进行转化。(3) OpenStack和Kubernetes的网络方案不同，融合后需要新的网络通信方案。

针对上述问题，分别提出了相应的解决方案，并进行了架构原型系统的实现，描述如下：

1) 虚拟机和容器共存的资源统一管理。在实现容器与虚拟机融合资源管理方面，原型系统基于OpenStack Placement项目进行了联合调度的数据接口定制，并重新编写了Zun和Nova服务模块的实时调度策略，支持在融合视图下的计算资源统一管理，如图8所示。

图8 OpenStack中Placement调度过程

相比原生Placement，本系统在实现过程中进行了如下能力增强[13]：(1) 打破原生Placement对虚拟机和容器资源分别单独管理的结构，重构了虚拟机与容器资源信息共享的管理机制，在资源管理与调度层面为超融合打下基础；(2) 为方便管理，将虚拟机与容器的底层数据模型进行统一化处理，并基于此对数据管理、业务逻辑等相关代码进行重新编写；(3) 在虚拟机与容器的调度策略中加入NUMA机制，实现了对底层硬件资源的精细化管理。

2) 虚拟机和容器共存的容器编排。一些方案已实现虚拟机和容器的编排调度[14-15]，在容器管理的设计上，在IaaS层通过OpenStack的Zun组件来创建容器，在PaaS层则通过Kubernetes对容器进行编排。但Zun管理容器的模型是Container，而Kubernetes编排容器的模型是Pod。由于IaaS层与PaaS层容器管理模型不同，两层无法直接对接。

本方案通过开发中间组件Virtual Kubelet(VK)，来实现两种不同管理模型的转换。VK组件作为Kubernetes与OpenStack信息交互的桥梁，首先要对Kubernetes的Master节点对容器的操作请求进行监听，然后在内部将请求信息中的POD数据模型转换为OpenStack可识别的Contaner数据模型，进而将请求下发至OpenStack平台。同样在OpenStack操作完毕后返回信息的时候，VK组件还要进行一次反向转换。同时为方便管理部署，本方案将VK注册集成至Kubernetes平台中。整体架构图如图9所示。

图9 OpenStack与Kubernetes融合设计架构图

3) 虚拟机和容器共存的网络模型解决方案。在网络融合对接上，本方案基于OpenStack已有的网络组件——Kuryr，与Kubernetes网络进行适配对接，定制化开发Kuryr-Kubernetes组件。该组件南向可调用Neutron接口，为上层提供实际的网络资源，实现底层网络功能，北向则实现了Kubernetes的标准网络CNI接口，为PaaS层的网络调度编排提供驱动，从而实现了虚拟机与容器网络方案的融合。

具体而言，Kuryr-Kubernetes使用Neutron LbaaS v2代替kube-proxy组件，解决了Kubernetes service映射到pod endpoints的问题。将service中的ClusterIP映射为LbaaS的vip，将service后面对应的podIP：port添加到LbaaS的pool中作为member。通过Kuryr-Kubernetes将Kubernetes和OpenStack网络融合，在Kubernetes网络实现的同时，确保了OpenStack Neutron作为统一的网络方案对容器和虚拟机的管理。容器间网络直接连接，不需要向下再包一层虚拟机网络，解决两次overlay性能差的问题。容器网络也可以使用Neutron中security group和floatingIP等功能，如图10所示。

图10 Kuryr-Kubernetes架构图

3.3 方案优势

虚拟机和容器的超融合技术实现了虚拟机和容器资源的共享，实现了资源统一管理，同时实现了容器的编排调度，可以带来如下优势：

(1) 提高资源利用率，降低成本。采用虚拟机技术和容器技术共同支撑应用，可以大幅增强资源的灵活调度，同时通过计算力的精细化调度进一步提升了应用性能。

(2) 实现容器虚拟机联合调度，可直接看到资源分配情况。完成虚拟机和容器资源的统一管理，实现运行大数据集群的容器和虚拟机的联合调度，虚拟机资源和容器资源互相感知。

(3) 对OpenStack构建的容器应用，通过与Kubernetes的融合，实现了高效的编排调度，提升对硬件资源的利用效率。

4 原型系统实践与实验结果

4.1 实验环境

整个原型系统由OpenStack控制节点、Kubernetes控制节点、OpenStack计算节点三部分组成。本实验搭建了8台物理服务器规模的实验环境，其中：1台为OpenStack控制节点，1台为Kubernetes控制节点，其余6台为OpenStack计算节点。整体实验环境部署架构如图11所示。

图11 原型系统部署架构

在网络规划上，为实现平台流量的安全隔离，整体原型系统有管理网、业务网和存储网三张网。管理网承载OpenStack及Kubernetes的服务数据，由于数据量较小，采用千兆网进行承载；业务网与存储网则负责具体计算与业务数据的传送，数据量大，对性能要求高，因此采用万兆网络进行承载。

本原型系统所有组件均基于OpenStack、Kubernetes、MariaDB等开源软件设计研发，相应软件版本情况如表1所示。

表1 实验环境软件信息

4.2 效果展示

1) 功能描述。为了展示容器与虚拟机超融合效果，该方案在OpenStack的DashBoard组件上(物理机信息页面)开发了资源使用情况信息展示功能。如图12所示，本文提出在物理节点上统一呈现所有已创建虚拟机与容器情况的思路，并给予实现。从中可以看到各自使用的NUMA架构信息——CPU信息和内存信息。

图12 物理机资源使用情况

2) 应用部署实验。在利用Kubernetes编排能力方面，实验通过模版导入的方式创建了基于容器的Hadoop集群，如图13所示。

图13 Hadoop容器集群信息

为了验证此架构的性能，与在物理机上运行的Hadoop集群性能进行了测试对比，对比结果如表2所示。可以看出，在运行相同任务的情况下，基于NUMA架构的精细化管理的容器集群取得了比物理机更好的效果。

表2 物理机和容器运行Hadoop集群性能对比

5 结 语

虚拟机技术和容器技术作为数据中心重要的虚拟化技术，在降低成本的同时为用户提供了高效便捷的服务，但虚拟机不够便捷，容器不够安全，未来数据中心将会融合两种方案为用户服务。本文针对目前数据中心融合方案进行了分析并提出了一种新的融合方案，在资源融合调度等方面取得了显著优势，进一步降低了数据中心的运营成本，融合方案也解决了融合后容器的编排问题，并通过实验验证融合方案可行。容器和虚拟机共存已成必然，统一的资源管理也会变得更加快捷、简单，在同一台物理机上部署虚拟机和容器势必会推动云计算技术向着更加完备的方向发展。下一步会继续对融合方案进行优化和完善，推动方案向生产应用快速演进。