丁玺润1,2，陈梅1,2，李晖1,2

　　（1.贵州大学 计算机科学与技术学院，贵州 贵阳 550025；2.贵州大学 贵州省先进计算与医疗信息服务工程实验室，贵州 贵阳 550025）

　　摘要：随着Docker等的问世，基于容器的操作系统级虚拟化技术受到云计算厂商的广泛关注。针对云平台上不同应用领域的数据库容器（面向事务型任务的数据库容器与面向分析型任务的数据库容器）在运行时对宿主机资源需求的差异，提出一种面向容器的数据重分布策略，用于优化容器中数据库服务的性能。实验结果表明，该策略达到了预期效果，可以有效提升容器中数据库服务的性能。

　　关键词：云计算；虚拟化；数据库；容器；数据重分布

0引言

　　以Docker为代表的Linux容器技术为云平台提供了更轻量级的虚拟化解决方案。Linux容器技术是一种内核虚拟化技术（即操作系统级虚拟化技术），它提供了轻量级的虚拟化解决方案。可以在一台主机上通过隔离进程和资源，同时提供多个虚拟环境（即容器）。每个容器都拥有自己的进程和独立的网络空间。从用户角度看，一个运行的容器与一台运行的主机无异。

　　基于容器的虚拟化技术通过隔离操作系统的对象，例如PID、UID、系统共享内存、IPC等，实现对不同容器提供不同的系统视图，并且通过Cgroups和Namespace技术实现。Linux容器技术在资源管理方面依赖于Linux内核的Cgroups，它是Linux内核提供的一个基于进程组的资源管理框架，为特定的进程组限定可以使用的资源。Linux在隔离控制方面依赖于Linux内核的Namespace，即将原来的全局对象隔离到不同的Namespace里，不同容器之间不可见。

　　目前，应用广泛的虚拟化技术包括以VMWare和微软的Virtual PC为代表的全虚拟化技术以及以Xen为代表的半虚拟化技术。与上述技术相比，容器级虚拟化可以直接运行CPU指令，避免全虚拟化指令级模拟或即时编译造成的系统开销，同时也避免了半虚拟化和系统调用替换的复杂操作。因此，容器级虚拟化技术比传统虚拟化技术具有更轻量级，但是容器技术强制所有容器必须使用与宿主机相同的内核。

　　文献［12］指出，运行在云平台上的服务，例如Web服务，容易受到网络带宽、CPU、内存的影响，导致其服务质量降低。传统的解决方案是迁移云平台上运行该服务的虚拟机到其他节点，即VirtualtoVirtual。云平台上面向容器的数据重分布技术与其类似，通过迁移一台宿主机的容器及其数据卷到另一台宿主机，以解决容器中服务的性能问题。本文针对云平台上数据库容器，设计并实现了LXCDDS，一种云平台上面向容器的数据重分布策略，用于提升云平台上Linux容器中不同类型任务（事务型和分析型）的数据库服务的性能。

1相关工作

　　1.1Docker

　　Linux容器技术（Linux Containers，LXC）起源于1982年，由于操作复杂和维护困难等原因一直没有得到广泛应用，直到Docker的出现，Linux容器技术再次受到业界认可。Docker是dotCloud公司发起的一个开源项目。它始于2013年初，采用Go语言实现，以Linux容器技术为基础，目标是“Build, Ship, Run”，即“一次部署，多处运行”。文献［34］中指出，对于开发和运维人员来说，最希望的是一次创建或配置，在任意环境中运行。Docker的出现使之成为可能。同时，基于操作系统级虚拟化技术实现的Docker，比传统的虚拟机技术更轻量化，更易于迁移和扩展。因此，本文采用Docker作为Linux容器技术的一种实现。

　　1.2Flocker

　　本文采用Flocker作为容器中的数据迁移工具。Flocker是ClusterHQ公司的开源项目，它提供了容器数据卷管理以及多主机Docker集群管理功能。数据卷是一个可供一个或多个容器使用的特殊目录，它绕过UFS，可以在容器之间共享和重用。Docker容器的数据卷可以用来存储容器中的数据，一旦Docker容器由于某种原因宕机，可以通过相应的数据卷恢复容器中的数据，因此，常用在提供数据库服务的容器中。

　　Docker容器的数据卷只能绑定在一台Docker宿主机上，不能迁移到集群中的其他节点。Flocker中的数据卷也称作数据集(dataset)，它可以随着容器迁移到集群中的任何节点。Flocker项目的核心是Control Service，它提供一个简单的REST API，Flocker Control Service使用Flocker API管理集群中的节点，通过Flocker API，开发人员可以在多主机集群中部署多容器应用，在集群中迁移容器及其数据卷。目前，Docker官方正在测试Flocker项目，并计划将其作为未来Docker数据卷管理工具。

2容器级数据重分布策略的设计与实现

　　2.1容器级数据重分布策略的设计

　　在Linux容器中可以运行各种应用服务，其中数据库服务是最常见的也是最重要的应用服务，因此，本文重点研究如何提升Linux容器中数据库服务的性能。

　　数据库服务按照应用领域可以划分为面向事务型任务的数据库(即OLTP型数据库)和面向分析型任务的数据库(即OLAP型数据库)。本文研发的容器级数据重分布策略旨在将这两种类型的数据库容器重新分配到集群中的不同节点，并且通过调整节点的系统配置，分别提升这两种类型的数据库服务的性能。

　　如图1所示，假设云平台上运行Linux容器的集群中有两个节点Node 1和Node 2，在这两个节点上分别运行着几个Linux容器，其中T代表OLTP型数据库容器，A代表OLAP型数据库容器。容器级数据重分布策略的本质是将这两种执行不同任务的数据库容器转移到各自的节点上，让同一种任务类型的数据库容器运行在同一台节点或同一集群上，即将T类型容器全部迁移到Node 1节点中，A类型容器全部迁移到Node 2节点中，最终状态如图2所示。

　　从并发角度分析：对于OLTP型数据库服务［56］，执行I/O操作比CPU计算操作占用更多CPU时间片。该服务的线程负责阻塞I/O，当某一线程因为I/O阻塞进入阻塞状态后，该线程的调度被操作系统内核停止，不再占用CPU时间片段。而其他I/O线程立即被操作系统内核调度，待I/O阻塞操作完成，原来阻塞状态的线程重新变成就绪状态时，可以被操作系统调度。因此，理论上，为图2中Node 1的所有容器进程设置更多的I/O密集型线程可以提升该节点中OLTP型数据库服务的效率。

　　相反，对于OLAP型数据库服务，CPU需要执行大量的连接、聚集操作，而对于这种计算密集型任务，进程中的线程越多，导致进程内每个线程的执行时间越短，从而影响数据分析效率。因此，理论上，为图2中Node 2的所有容器进程设置更少的计算密集型线程可以提升该节点中OLAP型数据库服务的效率。

　　综上所述，该容器级数据重分布策略从理论上可以提升Linux容器中数据库服务的性能。此外，出于简化运维和业务管理的需要，在同一数据中心中，通常也更希望将同类型业务部署在物理位置更靠近的集群节点中。

　　2.2容器级数据重分布策略的实现

　　在实际应用中有两种情况造成图1所示的不同类型的容器不均匀地分布在不同节点上。第一种情况，在数据库容器运行前，运维人员不清楚或未对数据库容器执行的任务类型进行分类，因此，导致面向事务型和面向分析型任务的数据库容器随机地分布到不同节点中。第二种情况，运维人员已经对数据库容器执行的任务进行分类，但由于运行同一类任务的容器的宿主机资源不足，不能让待运行的容器在这台节点上运行，而运行另一类任务的容器的宿主机可以满足这个容器的运行条件，因此它将运行在与自己不同任务类型的容器的宿主机上。

　　例如，如图2所示，T类型任务运行在Node 1上，A类型任务运行在Node 2上，此时有1个T类型任务容器待运行，恰好Node 1不能提供它运行所需的资源，而Node 2可以满足这个容器运行的条件，因此这个新的T类型任务的容器被部署在Node 2上。经过一段时间，两个宿主机中就会同时运行多种类型的容器。

　　对于第一种情况，不确定节点中运行的容器哪些是T类型哪些是A类型。由于每个正在运行的数据库容器都有一个通过容器ID与它绑定的数据卷，该数据卷中存储了该数据库的数据、日志信息以及配置信息，通过解析该数据库的日志信息，可以确定其执行更新操作和查询操作数目的比例，以及执行更新操作和查询操作消耗的时间。执行事务型任务的数据库，其更新操作频繁，日志中更新操作的比例很高，且执行查询操作消耗的时间较短。反之，执行分析型任务的数据库，其更新操作非常少，但是由于其经常做复杂分析操作，需要执行大量JOIN操作和聚集操作，查询执行时间较长。因此，可以确定节点中的容器哪些是T类型哪些是A类型。

　　2.3分布式环境下容器级数据重分布算法

　　算法1为分布式环境下容器级数据重分布算法。该算法核心思想：首先，确定节点Node中每一个数据库容器的类型Type；然后，对于不符合本节点容器类型的数据库容器，将其加入到待迁移队列MoveList中；最后，找到待迁移的目标节点TargetNode，判断其是否有足够资源运行该容器，如果条件满足，则通过Flocker完成容器迁移，否则等待资源。算法代码描述如下：算法1 Data Distribution Algorithm输入: NodeID, TargetNodeID, TypeNode, MoveList

　　输出: NULL

　　1: while true do

　　2:if HasNewContainers()=true then

　　3:for each c in ListContainers(NodeID) do

　　4:TypeContainer ( GetContainType(c);

　　5:if TypeContainer= TypeNode then

　　6:else

　　7:if IfNodeInList(c)=false then

　　8:AddMoveList(c,MoveList);

　　9:end if

　　10: end if

　　11: end for

　　12: end if

　　13: while (HasElmts(MoveList)=true and

　　HasRes(TargetNodeID)=true) do

　　14: e ( GetNextContainer(MoveList);

　　15: DataMovement(e);

　　16: RmFromMoveList(e, MoveList);

　　17: end while

　　18:end while

3实验结果与分析

　　3.1实验环境及实验方案

　　本实验使用的硬件及系统配置见表1。实验中使用的数据库容器是DockerHub提供的PostgreSQL9.4.4官方镜像，其配置为shared_buffers=128 MB，其他参数为PostgreSQL系统默认参数。实验使用标准的TPC-H benchmark对OLAP型数据库的数据分析性能进行测试，总数据量为1 GB。本实验同时使用标准的TPC-C benchmark对OLTP型数据库的事务性能进行测试。

　　实验一：4核CPU；

　　实验二：8核CPU内存8 GB硬盘120 GB， 15 000 r/min操作系统CentOS 7（内核3.10.0）Docker版本1.7.1Flocker版本1.0.3PostgreSQL9.4.4实验一和实验二的实验过程相同。首先，初始状态时两个节点中分别运行3个OLTP型PostgreSQL容器和3个OLAP型PostgreSQL容器，对其中的1个OLTP型PostgreSQL容器进行TPCC benchmark测试，同时对1个OLAP型PostgreSQL容器进行TPCH benchmark测试，得到实验结果。然后，采用容器级数据重分布策略将OTLP型数据库和OLAP型数据库分离，使得其中一个节点上运行6个OLTP型PostgreSQL容器，另一个节点上运行6个OLAP型PostgreSQL容器，分别对OLTP型PostgreSQL容器进行TPCC benchmark测试，对OLAP型PostgreSQL容器进行TPCH benchmark测试，得到实验结果。最后分别测试节点中仅运行1个数据库容器时的OLTP性能和OLAP性能作为参考，得到对此结果。

　　3.2实验结果分析

　　实验一的结果如图3、图4所示。图3中显示了执行容器级数据重分布前后数据库事务的性能对比结果。图3的横坐标为测试的数据仓库个数，每个数据仓库中有10个测试终端（Terminal）；纵坐标为tpmC（数据库每分钟处理事务数），tpmC的值越高，则数据库的OLTP性能越好。从图3中可以看出，节点中仅运行一个OLTP型数据库容器时，它的事务性最好，因为节点中没有其他容器与其竞争CPU等资源，本实验用其作为性能参考标准。数据重分布后容器中数据库的事务性能排在其后，因为数据重分布前节点中还有3个OLAP型数据库容器在执行复杂的表连接和聚集操作，占用整个节点的大量CPU时间片，导致CPU处理I/O操作的等待时间增加，所以执行复杂分析操作的数据库容器会影响OLTP型数据库容器的更新操作性能，导致事务性能下降。因此，执行容器级数据重分布有利于提升事务型数据库容器的性能。

　　图4中显示了容器级数据重分布前后数据库分析性能对比结果。图4中横坐标为执行TPCH测试的22条SQL语句，其中Q17和Q20包含了复杂的嵌套查询以及聚集操作，且由于postgresql的shared_buffers大小设置为128 MB，导致这两条语句的执行时间是其他语句执行时间的几千倍，因此不作为本实验的参考。

　　从图4中可以看到，数据重分布后数据库的分析性能下降很明显，查询语句响应时间比数据重分布前的响应时间长很多。通过监控节点的CPU和内存发现，由于本实图4实验一（b）数据重分布前后TPCH测试结果

　　图5实验二（a）数据重分布前后数据库分析性能对比结果验使用的CPU为4核，内存8 GB，数据重分布前节点共执行3个OLTP型数据库容器和3个OLAP型容器，CPU使用率达到70%~90%，内存使用7.27 GB，而数据重分布后执行6个OLAP任务，该节点上的CPU使用率达到100%，内存使用7.48 GB，这说明执行OLAP型任务的数据库容器会消耗大量 CPU时间片，而此时CPU使用率已经达到饱和，因此数据库的OLAP性能急剧下降。实验证明，当宿主机系统资源不足时会严重影响宿主机中容器的执行效率，因此在宿主机资源不足时，应该执行容器数据迁移，但如果待迁移目标主机的资源不足，则待迁移的容器应该等待，以免由于资源竞争引起容器性能降低。

　　实验二在实验一基础上将CPU增加到8核，来测试容器中数据库的OLTP和OLAP性能。实验结果如图5和图6所示。图5表明，节点中CPU和内存充足时，数据重分布后的数据库的OLAP性能普遍比数据重分布前性能好，其原因如下：图6实验二（b）数据重分布前后数据库事务性能对比结果

　　数据重分布前，执行OLTP任务的容器频繁占用宿主机的CPU时间片来处理I/O请求，导致执行OLAP型数据库容器的CPU等待时间增加。因此，数据重分布后的数据库的分析性能比数据重分布前要好。图6为数据重分布前后数据库事务性能对比。实验结果表明执行容器级数据重分布后数据库事务性能好，具体原因图3中同实验一（a）。

4结论

　　Docker技术的出现给Linux容器技术带来巨大的发展前景，同时也促进了云服务技术的发展与应用。本文针对如何提升运行在云计算平台容器中的执行事务型任务和分析型任务的数据库服务的性能提出了容器级数据重分布策略LXCDDS。实验结果表明，该数据重分布策略能够有效提升云平台上容器中数据库服务的性能。

参考文献

　　［1］ Wei Hao, YEN I L,THURAISINGHA M B. Dynamic service and data migration in the clouds［C］. IEEE COMPSAC, 2009:134136.

　　［2］ 石杰.云计算环境下的数据挖掘应用［J］.微型机与应用,2015,34(5):1315.

　　［3］ 吴军， 张轶君， 白光伟.Xen下虚拟机动态迁移优化策略的研究［J］.电子技术应用,2015,41（11）：128131.

　　［4］ 杨保华， 戴王剑， 曹亚伦. Docker技术入门与实践［M］. 北京：机械工业出版社, 2015.

　　［5］ QUAMAR A, ASHWIN KUMAR K, DESHPANDE A. SWORD: scalable workloadaware data placement for transactional workloads［M］. EDBT, 2013.

　　［6］ Li Yinan, PATEL J M. WideTable: an accelerator for analytical data processing［C］. Proceedings of the VLDB Endowment, 2014:907909.